Stewart, Robert skrev:
On Friday, June 26, 2009 6:35 AM Thorsten Ottosen wrote:
Christian Schladetsch skrev:
Types in object hierarchies usually don't expose their copy-constructor to avoid slicing. 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. [snip] Furthermore, and more importantly, you lose 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.
I know of use cases in which a similar container is used to hold homogeneous collections of objects by pointer, so cloning is irrelevant. Indeed, I recall that Rogue Wave had such containers available. Here's one: http://www2.roguewave.com/support/docs/hppdocs/tlsref/rwtptrvector.html.
Well, and the containers should also cnotinue to support that case.
Can't cloning be handled using a smart pointer in a value-based container?
Yes and no. The closest thing would be to write boost::clone_ptr<T>, but there are additional differences like e.g. - containers shrink instead of inserting null values - ptr_vector<Base> b = ptr_vector<Derive>() - completely disallowing null-values; clone_ptr<T> could do that too, but would not be movable in that case, which in turn would make it horrible inefficient.
That is, rather than make the pointer containers try to manage cloning, let them assume T is the most derived type rather than what might be a base type, and then supply a smart pointer for use with value-based containers to enable cloning. The smart pointer can call T::clone() or defer to a policy class to copy the T * it holds.
It's not that simple as I explain above. Anyway, the question of where the objects' memory should come from can possible be answered irrelevant of other issues. But I need lot of feedback from people using custom allocators to allocate everything. -Thorsten