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

Subject: Re: [boost] [cpo-proposal] presentation of the idea
From: Larry Evans (cppljevans_at_[hidden])
Date: 2013-08-22 11:14:00

On 08/22/13 09:52, Larry Evans wrote:
> On 08/20/13 07:44, Thorsten Ottosen wrote:
>> 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
>>>>>> <thorsten.ottosen_at_[hidden]> 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
>>
> 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.
> The do_{copy,move} would still have to know how to map the
> old pointer to the new pointer, if pointers were used.
> OTOH, if only offsets were used, then wouldn't simply using
> the vector<char>::swap work?  OTOH, the problem with using
> offsets is that any function taking the offset argument
> to access the actual polymorphic_object in the container
> of polymorphic_object's would have to be given, in addition,
> a pointer to that container.
> 
> OTOH, I'm wondering if borrowing from the code in a copying
> garbage collector would provide a solution.  For example,
> if the:
> 
>   std::vector<char> storage;
> 
> was the storage in the container, then when it was resized
> such that a new storage region needed to be used, then
> wouldn't the code in a copying garbage collector which
> changes all pointers in the from space to pointers in
> the to space solve the problem?
> 
> Just a  thought.  I've never written a copying garbage
> collector; hence, I may be missing something obvious.
> 
> -regards,
> Larry
> 
Some googling for "copy collector stl allocator" lead to:

http://computer-programming-forum.com/81-vc/cf24648b1c6c8921.htm

which talks about a similar problem with memory mapped files.