Boost logo

Boost :

Subject: Re: [boost] [review] The review of Boost.DoubleEnded starts today: September 21 - September 30
From: Thorsten Ottosen (tottosen_at_[hidden])
Date: 2017-09-26 16:32:32


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 <boost_at_[hidden]
>> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk