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

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 <
thorsten.ottosen_at_[hidden]> 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.