Re: [boost] [ptr_container] ptr_vector across DLL boundaries

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 
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;

with

   virtual Base::clone( boost::clone_allocator& ) const = 0;

Now, if the containers stored a clone_allocator instance, it could be 
implemented like

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.

-Thorsten