Re: [hub] Post-review version ready

On Wed, 27 May 2026 at 21:37, Joaquin M López Muñoz <
[email protected]> wrote:

> El 27/05/2026 a las 2:29, Matt Bentley escribió:
>
> Hey Joaquin,
>
> thanks for our personal discussion on this stuff, I think we've both
> improved our respective containers.
>
> Thank _you_, it's been a most instructive exchange.
>
> Just to chime in in a more official capacity, good to see you've provided
> some post-iteration erasure results, I think that balances things out a
> bit, though it still lacks some longitudinal churn testing.
>
> ? Post-erase iteration benchmarks were there all along. Maybe the
> confusion arises because what used to be called "for_each" and "visit all"
> is now called "range for" and "for_each" respectively, after the syntax
> change proposed by Andrzej (namely, replacing visit[_while] member
> functions with global std::algorithm-like for_each[_while] functions).
>

Ah, I see.


> boost::container::hub does not conform to the specification of std::hive
> in a few aspects:
>
>    - Minimum and maximum block capacity limits can't be specified and are
>    fixed to (to 64 in this implementation). The std::hive spec allows for
>    this, but due to this we've decided to not provide reshape() or
>    constructors which take capacity-limit arguments, since these would not
>    result in any effect on the instance's capacity limits. In
>    addition block_capacity_limits(), block_capacity_default_limits() and
>    block_capacity_hard_limits() are not provided as they would always return
>    64, 64.
>
> Yes, I can rewrite that part. As you have pointed out here and elsewhere,
> the non-conformance is, strictly speaking, not a technical one, as
> boost::container::hub could always provide a dummy hive_limits interface.
>

Probably a good idea, if you want people to be able to swap in/out the
different container styles.


> Also, if you intend to fix that behaviour we talked about regarding
> iteration/visitation performance degradation over time (due to blocks which
> become empty not being moved to the tail of the 'available' list, and
> non-empty blocks thereby not being preferentially-used during insertion,
> resulting in greater gaps during iteration) you can remove the line
> "trim_capacity is linear on the number of available blocks
> (std::hive::trim_capacity is linear on the number of reserved blocks, i.e.
> those without any used slot).". As, once that aspect is fixed that it
> becomes possible to implement trim_capacity() as linear in the number of
> reserved blocks, by iterating backwards from the tail and stopping once a
> block with active elements is found.
>
> After our talk I went and did exactly as you suggested:
>
>
> https://github.com/joaquintides/hub/compare/feature/review-feedback...feature/linear-reserved-trim_capacity
>
> I'm measuring performance right now but seems like this is not producing
> any real degradation, so it'll go in. This also removes one of the
> non-conformances of boost::container::hub wrt to std::hive spec.
>

Sounds good - I'll check to see if there's any performance change in the
longitudinal tests afterward, if I get time.
I'll add a note re: forced inlining. In the past I enabled this for some
things like operator++, but found it pessimised. The compiler seems to be
much better at this that we are. However, you'd need to measure
before-and-after stats for your own case - not against my container (as
forced inlining will definitely preferentially inline some of your code),
but against your own pre-removal readings. Removing my container from that
benchmark would probably help to get accurate results in this particular
case.



> Finally a note re: Andrezj's container category note, this is a hive-lite
> container, therefore a sequence container, according to the standard:
> "organizes a finite set of objects, all of the same type, into a strictly
> linear arrangement". "In addition, array and hive are provided as sequence
> containers which provide limited sequence operations, in array's case
> because it has a fixed number of elements, and in hive's case because
> insertion order is unspecified.". "Limited" in the case of hive means no
> insertion position in insert/emplace functions. Otherwise there are no
> pragmatic differences.
>
> This stemmed from an objection by Andrzej. Originally hub was presented as
> a sequence container, much in line with the standard text for std::hive,
> but I then leaned towards Andrzej's stance that this is misleading because
> the core functionality that makes a container a sequence, namely control of
> positioning, is not provided. I guess the committee does not have the
> appetite (understandably so) for making great rearrangements of the text,
> but IMHO this would have called for a new kind of "unordered containers".
> Anyway, the current writing is a bit in between, it doesn't call the
> container a sequence container right away but then in the reference it
> states (
> https://github.com/joaquintides/hub/tree/feature/review-feedback#class-template-boostcontainerhub
> ):
>
>
>
> *boost::container::hub<T, Allocator> is also a model of SequenceContainer,
> with the following exception:     * Positional insertion operations of the
> form insert(position, ...) or emplace(position, ...) are not provided or
> ignore the position argument.*
>

Yes, they're mostly grouping categories, rather than technical categories,
since technically std::map also presents elements in a linear sequence if
you iterate, but regardless of any hair-splitting I think your wording is
good!
Cheers,
M@
_______________________________________________
Boost mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://lists.boost.org/mailman3/lists/boost.lists.boost.org/
Archived at: https://lists.boost.org/archives/list/[email protected]/message/MTX2EZM4DXES64IYFCTNEZCSKPHYPRKH/