Christian Schladetsch skrev:
Hi Thorsten,
On Sat, Jun 27, 2009 at 11:48 AM, Thorsten Ottosen < thorsten.ottosen@dezide.com> 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