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 07:59:17

On 16-08-2013 15:33, Larry Evans wrote:
> On 08/16/13 06:00, Thorsten Ottosen wrote:
> [snip]
>>> - The classifier uses continuous storage in memory for objects of the
>>> same type, therefore it is expected to improve cache efficiency with
>>> respect
>>> to solutions that use pointers (and new to allocate objects),
>>> especially if the
>>> client code uses some cache-aware allocator.
>>
>> I wanted to call my class template polymorphic_vector, taking base class
>> and allocator template arguments. I imagined that the storage
>> would be completely contigious, even when many different types of
>> objects where stored into the container. This would give maximum cache
>> efficiency.
>
> Hi Thorsten,
>
> I'm curious how you'd be able to store different types in contiguous
> storage. I would guess the base class would have to have a virtual
> derived_alignof and derived_sizeof methods which would
> return alignof(Derived) and sizeof(Derived), and then the container
> would use placement new and these virtual functions and a
> container_buffer type std::vector<char> to figure out where
> to place the next element in the container_buffer?

That sounds like the basic idea. Alignment may not be needed if we 
assume some kind of maximal alignment. Sizeof may not be needed either
if the syntax for adding objects is

   cont.push_back<Derived>( x, y );

>
> Since boost::fusion::vector<T1,T2,...,Tn> stores different
> types, T1,T2,...,Tn in contiguous storage, I'm wondering
> why not use boost::fusion::vector?

So this vector has no requirement on the size of the container (at 
compile time)?

I guess fusion::vector uses some kind of variant storage approach? If 
so, a lot of space may be wasted if Derived1 is small and Derived2 is large.

Also, We would really like not to have T1,T2,...,Tn to be complete types 
when using a polymorphic_vector, and we would really like not to
mention all the potential types stored up front.

regards

Thorsten