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