Boost logo

Boost :

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

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

Joaquín M López Muñoz

Boost list run by bdawes at, gregod at, cpdaniel at, john at