On Wed, Mar 5, 2025, at 16:06, Matt Bentley via SG14 wrote:
> Hi all,
>
> I'm just wondering what people's assumptions are around
> hive::assign()/fill-insert/range-insert and capacity. This is not a
> standardisation question.

My assumption is that the size is unspecified and implementations will run various performance measurements to figure out what is best. As hardware changes and/or algorithms advance: the best answer will change. Embedded will probably want a different answer (if they even use hive). Different implementations will have different answers.

The real question is are there performance characteristics that are important enough (after amortization) to encode in the standard? I can't think of any, but I want to leave this open in case someone else can.

> 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.

If assign knows the final size it may deallocate all blocks and allocate one new block that is larger than the current capacity, even though all the data would fit in the current capacity (across 2 blocks). I doubt any would in the real world, but I would not be surprised.

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

While I know that is the case because of how they are implemented, in general I do not expect that and I discourage anyone writing code that expects that. Sometimes in tight loops you need to rely on such details, but in general I want my fellow developers to just trust the library and worry about writing good code. This is an implementation detail.

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

Anyone who has any expectations should channel their inner Andrei Alexandrescu and give a talk at CppCon. There are times and places where this matters, but they should be advanced and complex. If these things matter often I expect implementations to have an extension so those to whom it matters can select behavior (likely a future paper adding it to the standard)

These details are important to library implementers. Users of the library just want a good compromise between various performance and memory usage issues so they don't have to worry about this.