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 cc.capacity() cc.capacity(index) cc.capacity<U>() 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 segments." 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?