On 1/20/25 5:09 AM, Richard Biener wrote:
On Sat, Jan 18, 2025 at 1:02 AM Jason Merrill <ja...@redhat.com> wrote:

I notice that the second argument to vec_safe_reserve is the number of
empty spaces to provide, rather than the new desired capacity.  So this
will allocate space for an additional copy of the whole constructor.

I guess you want to say reserve (ret, nelts - vec_safe_length (res))?
It's weird that there isn't a more convenient way to express that.

Note that this behavior differs from the C++ standard library, where
reserve indeed specifies the new capacity.  This seems likely to cause a
lot of confusion (and over-allocation) going forward.  And indeed
looking through exising uses turns up at least two that seem to assume
the standard library semantics (as well as others that assume the actual
semantics).

I wonder about renaming the existing reserve to reserve_space and adding
a reserve_capacity?

To me that's equally confusing.  To me our ::reserve semantics is sound,
but I can see if you know std::vector by heard that you're easily confused.

IMO std::vector::reserve (1) doing nothing when .length () == 2 is confusing,
I asked it to reserve some space!  So, can we fix the standard library instead?
(OK, just joking)

We do have the issue of branch maintainance when doing any change here,
so we can't change the semantic of ::reserve but we'd have to remove it.

Agreed.

I'll note we have ::space to query free capacity while the standard library
only has ::capacity.  So iff then we should simply rename
::reserve to ::reserve_space, but not adding another (confusing) variant.

You don't think there should be a way to specify a new minimum capacity without subtracting the current length?

Jason

Reply via email to