On 20-08-2013 14:11, Larry Evans wrote:
On 08/20/13 06:55, Larry Evans wrote:
On 08/20/13 04:23, Thorsten Ottosen wrote:
On 20-08-2013 11:04, Rob Stewart wrote:
On Aug 19, 2013, at 9:44 AM, Thorsten Ottosen
wrote: Yes, at this level it is nice to take advantage of the memcopying built into vector<char>.
Here's the problem. Replicating the bits of and object isn't the same as copying it. Many classes store a this pointer or rely on a data member address as a unique key, etc. Copy constructors must run.
Good catch. Thanks Rob.
However, this is a specific case of a more general problem. Suppose the polymorphic_object at container[i+j] contains a pointer of the polymorphic_obect at container[i]. Then after resizing, the pointer will become invalid. The specific case Rob mentions is when j=0.
Maybe the class should just warn the user not to do this or suggest a workaround, maybe instead of storing a pointer, just store the index into the container?
Pointer stability is an /inherent/ "problem" compared to using e.g. ptr_vector<T>. I see no other solution than warning the user about pointer invalidation, and advice the user to fill the container before storing any pointers in other places, or as you say, to use indexes. Since we need a base class, then maybe somthing like this is a starting point: class polymorphic_object { public: virtual ~polymorphic_object() {} private: polymorphic_object( const polymorphic_object& ); polymorphic_object& operator=( const polymorphic_object& ); public: static void copy( const polymorphic_object& this_, char* to ) { // preconditions this_.do_copy( to ); // postconditions } static void move( polymorphic_object& this_, char* to ) { // preconditions this_.do_move( to ); // postconditions } private: virtual polymorphic_object* do_copy( char* to ) const = 0; virtual polymorphic_object* do_move( char* to ) = 0; }; regards Thorsten