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

22 Aug 2013

      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
 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.