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-19 08:22:54

Hi Larry,

>>
> [snip]
> The attached demonstrates, I believe, what Thorsten was aiming at
> an shows the storage of *different* types in contiguous storage.
>

I was hoping this could be done a lot easier. My outset is that objects 
are added by saying

   // in-place contruction by forwarding x and y
   cont.push_back<Derived>( x, y );

This should give maximum information about the size and alignment of 
Derived to the container, allthough I was hoping that some kind of 
maximal aligment could be assumed, eg. 4 bytes boundaries on 32 bit 
systems. I see no limitation in adding the elements
this way, as it completely mirrors a container of pointers:

   ptr_container.push_back( new Derived( x, y ) );

So far so good. The polymorphic_vector< class Base, class Allocator > 
class template would internally only need an std::vector<char>. The 
question would be how to copy the objects? This is where I imagined
the base class requirement should enter, that is, the base class of the 
class hierarchy should inherit from boost::polymophic_object which has a 
single function:

unsigned copy( char* into, const char* from )
{
    // inplace copy or move
    return sizeof(Derived);
}

In any case, I would rather see virtual functions to be added to this 
interface if it removes the need to store things like size/alignment.

When saying

   // in-place contruction by forwarding x and y
   cont.push_back<Derived>( x, y );

we should also store a pointer to the next element to allow forward 
iteration, so maybe a start and end pointer also needs to be stored 
directly in the container. Perhaps this can be avoided by just letting 
the user get a pointer from push_back.

-Thorsten