Support construction with allocators for allocator-aware types - #24
justusranvier wants to merge 1 commit into
Conversation
Add a constructor and type trait specialization which is active if T is allocator-aware This allows a std::shared_ptr for a guarded type to be constructed with std::allocate_shared.
|
Thanks for submitting this, it does look like a useful feature. However, I looked at this recently and started to add some unit tests for the new functionality, and realized that something seems strange with the implementation of the uses_allocator specialization. Can you give an example of a T where the uses_allocator trait is expected to be true? It would be good to have a use case. |
|
The complication is that there's two ways to get the uses_allocator trait: the leading-allocator convention and the trailing-allocator convention. This PR only works with types that use leading-allocator convention, in other words if the first argument of the constructor is Somebody who is better at TMP than me could probably adapt it to also work with trailing-allocator convention, but all the types I want to guard are leading-allocator and supporting both conventions would likely be a much more intrusive change. You might need to add new template parameters to every class. |
|
Here's an example of a leading-allocator convention type, showing how it can be constructed with or without allocator construction: |
|
The goal would be able to write And then pass the resulting |
Add a constructor and type trait specialization which is active if T is allocator-aware
This allows a std::shared_ptr for a guarded type to be constructed with std::allocate_shared.