On 31/10/2017 07:27, Thorsten Ottosen wrote:
Sure, we can make new semantics. I think Joaquin's concern was that if we provide both capacity() and reserve(), we better do it 100% compatible with vector.
In our source code, I found just one mention of capacity(). In the dependencies, less than fourty. And only one involved a comparison with size(). That one in 800-900k lines of code. Other code bases may be different.
At least for vector, I think most codebases make the assumption that capacity() will always return a value >= the value passed to reserve(), and reason that they're therefore allowed to emplace/push_back() up to or equal (reserve-argument minus size()) times without causing further allocation or iterator invalidation, and without needing to explicitly check the capacity. It is likely that they would be able to call it even more times (as reserve() typically rounds up), but most code would not care about this or attempt to do so. (It's also probably most common that size() == 0 when reserve() is called, but not guaranteed. In cases where it is not, it is then probably most common to use reserve(size() + N), where N is the number of push_backs you want to make without reallocation/iterator invalidation.) Unit tests might be more picky. I don't know whether devector should try to emulate these patterns (which might cause over-allocation of the back end) or just require people to use reserve_back()/size_back() explicitly instead.