Christian Schladetsch skrev:
[snip]
Then what is the point of clone_allocator?
It does provide some room for customization. But it was deliberately kept very conservative, so we can extend it when we need to in light of user experience.
Isn't being able to create a clone using the parent containers' allocator a practical necessity? The originals are made using that allocator - isn't it natural to make clones using the same allocator?
It might be. I don't know. But see below why it is not that easy.
Types in object hierarchies usually don't expose their copy-constructor to avoid sliving.
But again, isn't this out of the scope? It's like the tail wagging the dog - ptr_container shouldn't really be concerned with object hierarchies or not. That's up to the user.
Surely, copy construction must be the best default way to make a clone? The user can make their types noncopyable if needed.
Furthermore, and more importantly, you loose the concrete type of the objects by having a container of pointers to the base class. Virtual functions are the most elegant way to ask the object for a copy of the right type.
Isn't this about ptr_container? We can't really have the specific usage of OO hierarchies with containers of base pointers dictate the implementation of an otherwise general system.
Please understand that pointer containers are written almost for the sole purpose of supporting OO programming better.
[snip] This requires a public copy-constructor which we must not impose as a requirement, and even so it would not work because the concrete type is lost. (let's ignore that it is not exception-safe).
How will you make a clone without using a copy-constructor? Are you suggesting something like is_convertible<base *, T*> then switching to a virtual-method-based-scheme for clone??
I don't fully understand what you mean by "the concrete type is lost". Do you mean in this sort of case?
struct Foo { vector<Base *> bases; Foo(const Foo &other) { ... /* how to clone bases? */ } };
If so, isn't that way out of the domain being addressed by ptr_container?
When you assign Base* p = new Derived; the concrete type of Derived is lost.
I think I see that you wanted a way to help with the Foo case above, but perhaps that really shouldn't be a part of ptr_container at all?
It's one reason the containers exist. But it's not just for the copy-construtor case.
And, as stated above, we also need to make sure that implementers of clone() get the allocator.
It seems that you added clone_allocator to help with cloning of containers-of-base-pointers, but I can't see that working in general. Attempting to do so is really reaching from system library space into application space.
If needed, the user can make their own clone() system, and use it to implement their own copy constructors, which would then be used by allocator::construct in a ptr_container to make a clone and clone_allocator then isn't even needed.
I don't want to repeat myself, but pointer containers need to support non-copyable types. Period.
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. -Thorsten