Re: [boost] [poly_collection] Request for comments: fast polymorphic collections

Subject: Re: [boost] [poly_collection] Request for comments: fast polymorphic collections
From: Joaquin M López Muñoz (joaquinlopezmunoz_at_[hidden])
Date: 2016-12-02 03:21:37

El 30/11/2016 a las 17:10, Thorsten Ottosen escribió:
> On 23-11-2016 21:19, Joaquin M López Muñoz wrote:
>> El 23/11/2016 a las 18:23, Thorsten Ottosen escribió:
>>> C. Could the segment type be a template argument, or is there good
>>> reasons for not dong that?
>>
>> Like replacing std::vector with some other contiguous-memory container?
>> This can certainly be done but I fail to see any reasonable use case for
>> that. Also, the library is extremely sensitve to the requirements
>> imposed on stored concrete types (moevability etc.) which are precisely
>> coded for std::vector but may dffer wildly for other vector-like
>> containers.
>
> The downside of using std::vector is then that you are stuck with that 
> behavior, and that the behavior is different on different platforms. 
> E.g., a resize may double the capacity or grow by 50% etc. This may be 
> fine for vector, but could hurt a little more here.
>
> I certainly have class hierarchies where the size of some classes is 
> very small and for others it is an order of magnitude larger.
>
> Doing
>
>   coll.reserve( x );
>
> then potentially ends up eating much more memory then the normal 
> vector case. Maybe we should only have reserve for specific types?
>

I think all-segment reserve is convenient as there are use cases that 
can't be
done easily with segment-specific reserve, such as

"make sure *registered* types can't hold N elements without reallocation"

Doing this without reserve is possible but awkward and sub-optimal wrt 
efficiency:

   for(auto s:c.segment_traversal()){
     c.reserve(s.type_index(),N); // incurs an internal lookup on 
std::type_index
   }

Joaquín M López Muñoz