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
> 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.
> 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
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
c.reserve(s.type_index(),N); // incurs an internal lookup on
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk