On Fri, Jun 26, 2009 at 9:26 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> wrote:
Christian Schladetsch skrev:
How does a clone_allocator make a new clone, if it needs access to the allocator in the parent ptr_container? [snip]
What am I missing?
Nothing, I think. This seems like something it was not designed for, on the cnotrary the clone is currently always allocated by someone else.
Then what is the point of clone_allocator?
The current design uses static functions, and so there can be no stateful allocator.
I thought a little about this, but have not come up with a solution. For example, how do we design an allocator that knows how to clone a class hierarchy? Only the class itself knows how to clone itself because it knows the exact type. OTOH, the classes in the class hieararchy doesn't know about the allocator.
We might try a new way to clone objects by replacing
virtual Base::clone() const = 0;
Isn't this what a copy constructor is for? I've had a quick look at <boost/ptr_container/ptr_inserter.hpp> and related files, and it seems that whenever it currently says something like obj = container_type::clone_allocator_type::allocate_clone(*r); it could say instead obj = container_type::clone_allocator_type::allocate_clone(*r, cont.get_allocator()); And then in a custom clone_allocator, you could say: struct my_clone_allocator { template< class U, class Allocator > static U* allocate_clone( const U& r, Allocator &alloc) { typename Allocator::template rebind<U>::other my_alloc(alloc); U *clone = my_alloc.allocate(1); my_alloc.construct(clone, r); return clone; } } Or, pass in a rebound allocator to allocate_clone; it doesn't really matter. Point being, can you just pass the container's allocator to the clone_allocator? Another alternative is to make clone_allocator a concept and pass the either-or-both U and Allocator types to it at compile time, but I think it works just as well and more generally as a static method. Regards, Christian.