Re: [boost] [cpo-proposal] presentation of the idea

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2013-08-22 11:38:33

On 22-08-2013 16:52, Larry Evans wrote:
> On 08/20/13 07:44, Thorsten Ottosen wrote:

>> 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
>>
> Hi Thorsten,
>
> I'm not sure how these do_copy and do_move virtual member functions
> would work differently than just using the derived copy CTOR's.

We know the exact type in

   cont.push_back<Derived>( ... )

but at the time when the container needs to move/copy elements around,
the exact type of the objects has been lost. All we know is that in

    polymorphic_vector<Base>

the elements are somehow derived from Base. Hence we can't call the
the CTOR's. To get to the next element, I guess we need a virtual 
object_size() function too.

> The do_{copy,move} would still have to know how to map the
> old pointer to the new pointer, if pointers were used.

Yes, the derived classes' do_{copy,move} would call their respective
constructors. The postcondition in copy/move would assert that
the newly constructed object is of the correct type, using typeid.

If you want to make the class automatically track pointers stored inside
derived classes pointing to other derived classes, then I think it is 
way to complicated. The user should be adviced/required to construct all 
the elements and then set up pointers if that is needed.

> OTOH, if only offsets were used, then wouldn't simply using
> the vector<char>::swap work?

Doesn't that have the same problems as memcpy'ing? That is, if we don't
call the constructor, we don't get the implicit stuff inside the
classes properly constructed.

regards

Thorsten