On 05/03/2025 23.06, Matt Bentley via SG14 wrote:
> I'm just wondering what people's assumptions are around hive::assign()/fill-insert/range-insert and capacity. This is not a standardisation question.
>
> The standard ([sequence.reqmts]) does not specify one way or another whether capacity changes as a result of a call to assign(), but obviously if the assigned range is larger than capacity(), capacity() will increase.
>
> However, if the assigned range is smaller than capacity, would capacity be expected to decrease? Or rather, what would /you /expect to happen? Leave capacity as-is, avoid deallocations and put the burden on the developer to call trim()? This has implications for whether or not assign does the right thing by cache locality ie. maintaining the minimum number of larger contiguous blocks, or by allocation/deallocation.

I can't parse this last sentence.

For assign(), you first need to destroy all elements that are currently
stored in the std::hive (iteration over the contents). That results in a
bunch of empty blocks, which are then (partially) filled from the arguments
to assign().

Allocation/deallocation might be (comparatively) expensive, so I think
I want to keep the excess empty blocks by default. Have the user
call trim() if they want otherwise.

This way, you offer both options. If assign() always trims, you're stuck
with that.

> For vector, we would possibly expect capacity to stay the same in this case. For list, we expect it to decrease.

std::list does not have a capacity.

> Similarly, would you expect a call to hive::insert(num, element) when size() == 0 but capacity() > num to potentially decrease capacity()?

No, same rationale.

Jens