Subject: Re: [boost] [ptr_container] ptr_vector across DLL boundaries
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-06-25 17:26:38
Christian Schladetsch skrev:
> How does a clone_allocator make a new clone, if it needs access to the
> allocator in the parent ptr_container? I had this problem when I tried to
> write a clone allocator for monotonic to support ptr_containers:
> struct inline_clone_allocator
> template< class U >
> static U* allocate_clone( const U& r )
> // can't allocate clone without access to the allocator??
> return 0;
> 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.
The current design uses static functions, and so there can be no
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;
virtual Base::clone( boost::clone_allocator& ) const = 0;
Now, if the containers stored a clone_allocator instance, it could be
struct my_clone_allocator : boost::clone_allocator
template< class U >
U* allocate_clone( const U& r )
return r.clone( *this );
(remark: boost::clone_allocator would have two virtual functions: void*
allocate(unsigned) and void deallocate(void*)).
That might work, but it still gives you no guarantee or possibility that
derived classes use the container's allocator for all its data members
(reqursively). Maybe that is not required; I just don't know.
So feedback on what we want to do is most welcome.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk