Den 10-10-2017 kl. 00:12 skrev Ion Gaztañaga via Boost:
On 09/10/2017 10:30, Thorsten Ottosen via Boost wrote:
What if we did this:
capacity() -> alias for back_capacity back_capacity() -> return size() + back_free_capacity() front_capacity() -> return size() + front_free_capacity()
?
I think it's very confusing. If we move elements while inserting on one end and the free capacity of that end is zero, then capacity() has sense, it's the limit where memory will be reallocated.
Let's not mix moving in push_back/push_front with reallocation (*). The above definition solve exactly what you and Joaquin saw as a problem while at the same time /generalizing/ the vector behavior for both ends. If we have - as free space and x as elements, then -----xxxxxxxxxxxxx--------- ^^^^^ front free capacity ^^^^^^^^^^^^^^^^^^ front capacity ^^^^^^^^^^^^^ size ^^^^^^^^^ back free capacity ^^^^^^^^^^^^^^^^^^^^^^ back capacity (a.k.a capacity) The limit where new memory is acquired for insert can be found easily enough. Basically we can't both generalize vector behavior and get the segment size in one function. So pick one or none. Two of them allow generic code to compile. kind regards Thorsten (*) If push_back/push_front steals memory from the other end, we should be cautious about when this is done (potentially high constant factors as mentioned in the analysis you found). But it is more than that: it may mean that push_back/push_front cannot give the strong exception-safety guarantee. Are you really given that away for Boost.Container's vector? (I hope not).