Subject: Re: [boost] [ptr_container] ptr_vector across DLL boundaries
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-25 19:22:25
On Fri, Jun 26, 2009 at 9:26 AM, Thorsten Ottosen <
> 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
> 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
it could say instead
And then in a custom clone_allocator, you could say:
template< class U, class Allocator >
static U* allocate_clone( const U& r, Allocator &alloc)
typename Allocator::template rebind<U>::other
U *clone = my_alloc.allocate(1);
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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk