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-27 06:12:13

Christian Schladetsch skrev:
> Hi Thorsten,
> 
> [snip]
>> able to copy e.g. ptr_vector<Base>
>> is a key property of the library, and there is no way that
>> is going to be removed from the library.
>>
>> You can accept that or not. If you don't, we have nothing more to discuss.
>> If you do, I would be happy to work
>> with you and others to make the library even more useful, including
>> finding someway of supporting that all memory is allocated from
>> the same underlying allocator.
> 
> 
> I have no problem with the library in general. I simply found it impossible
> to make a clone when using it. I've made my suggestion of passing the parent
> allocator to the clone_allocators static clone method. I'm happy to leave it
> at that.
> 
> At the end of the day, I just change my local branch anyway ;) I'll think
> about a way of doing it that you may find preferable over passing the
> allocator to the clone_allocator.

Thanks.

I see two problems we need to  solve:

1. how to specify that cloning should use memory from the normal 
allocator (not the clone allocator). This is particular tricky
for class hiearchies which are not copyable.

2. How to copy with mixed memory. Either the allocator is responsible 
for all heap-allocated object or it is responsible for none of them.
Currently it is resposible for none of them, and global new/delete
is resposible. If the allocator was responsible, how would we fill
the container? Would we require the user to do

  cont.push_back( new (cont.get_allocator().allocate(sizeof(T)) T(...) )

or should we add emplace() functions s.t.we can say

  cont.emplace_back( ... )

One might argue that all overload of push_back() that take a naked
pointer or auto_ptr are dangerous in this scenario, so maybe we should
look into ways to disable them at compile time.

-Thorsten