Subject: Re: [boost] [poly_collection] Request for comments: fast polymorphic collections
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2016-11-23 12:23:05
On 19-11-2016 10:09, Joaquin M LÃ³pez MuÃ±oz wrote:
> El 18/11/2016 a las 11:56, Thorsten Ottosen escribiÃ³:
>> It also seems natural to expect that capacity() - size() for a
>> container to tell us the number of elements I can insert without
>> reallocation will happen, and hence is important if one want to reason
>> about exception-safety. With the exotic definition of capacity() that
>> is no longer the case.
> Here I don't see an alternative: please note that c.insert(x) can
> *never* guarantee no memory allocation because x can be of an as-of-yet
> unregistered type, which will force the creation of a new segment etc.
OTOH, if we know the type is registered ... and there is also the
reverse statement: if capacity is 0, I know the thing can throw.
> So, we can only provide capacity information for *registered* types,
> which is precisely what the exotic definition of capacity() does. Do you
> see any other viable definition?
Hm. Maybe not. We have
and the first is specified as
"the minimum return value of capacity for each of the segments of the
collection, or std::numeric_limits<size_type>::max if there are no
I can't see how that is useful for much. The segment specific ones are
useful, of course. I would still say it should return 0 if there are no
segments, or that it should not be provided at all. If provided, it
should follow size() which I assume sums over all segment sizes. That
is, it should sum over all capacities.
Here are some design questions:
A. Do we want these two states to be independently observable:
- empty, but with empty segments
- empty, but with no segments
B. If I call shrink_to_fit on an container with empty segements, does it
end up with no segments?
C. Could the segment type be a template argument, or is there good
reasons for not dong that?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk