Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30

Den 25-09-2017 kl. 23:13 skrev Benedek Thaler via Boost:

On Mon, Sep 25, 2017 at 2:52 AM, Zach Laine via Boost

...

wrote:

...

There are no standard containers for which capacity() == 16 implies that when there are three elements, an allocation will occur when I add a fourth. That's substantially odd. It means that as a user I must know about extrinsic state information (how many pushes were to the front or back) in order to predict memory usage and the number of allocations even roughly.

No need for extrinsic state info, there are the front_free_capacity() and back_free_capacity() members.

1. vector's capacity says nothing about whether the next push_back will allocate 2. there are containers that allocate on every push_back/push_front, so why is this odd? 3. we have different options here. I don't suppose you object to the fact when a small buffer is specified, then the small buffer size is also the initial capacity? So the choices we have is where to distribute the capacity between front_free_capacity and back_free_capacity: A. divide it as evenly as possible B. maximize front_free_capacity C. maximize back_free_capacity Currently, devector does (C) and provide means for the user to choose the capacity at both ends. What would you prefer instead?

...

I don't understand why should_shrink() is part of GrowthPolicy. If I'm growing the container, why am I worried about shrinking it?

Because next time you can avoid growing it.

To add to that: shrinking involves allocating a new buffer and copying or moving elements to the new buffer, which may be very expensive. Say you feel this is not worth doing if the amount of reclaimed memory is less than 5 percent (i.e. the vector is at +95% capacity). kind regards -Thorsten