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 04:29:42

Christian Schladetsch skrev:
> Hi Thorsten,
> 
> On Sat, Jun 27, 2009 at 11:48 AM, Thorsten Ottosen <
> thorsten.ottosen_at_[hidden]> wrote:
> 
>> Christian Schladetsch skrev:
>>
>>  PS. Perhaps just porting ptr_container to use boost::container rather than
>>>>> std::container would solve Roberts problem?
>>>>>
>>>>>  No. He needs to "install" his own new/delete with the container.
>>> Isn't this called a stateful allocator? Which boost::container supports?
>>>
>> Hm. Is it? So construct() and destroy() would act as custom
>> allocator/deleter?
> 
> 
> No, the custom allocator would act as a custom allocator. Obviously I don't
> follow this.  If you want to "install" custom new and delete into a
> container, isn't this best achieved by using a stateful allocator? If so, it
> seems the best want to support stateful allocators is to base ptr_container
> on boost::interprocess::containers (hopefully soon to be boost::containers)
> rather than std::containers.
> 
> It seemed to me that Robert needed stateful allocators for ptr_containers.
> You said he didn't. But now you made clone_allocator stateful, but left the
> normal allocator stateless. I'm confused.

If he makes a container with a custom clone_allocator, differente 
container objects might not need the same to allocate and delete 
objects. Therefore he needs a statefull clone_allocator.

Christian, a comment on the rest of your mail: you are completely 
allowed to question the design
of the library, but being 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.

-Thorsten