Re: [hub] Post-review version ready

Hey Joaquin,

thanks for our personal discussion on this stuff, I think we've both 
improved our respective containers.

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.
If you want, you're welcome to link to my benchmarking in your docs.
I realised visitation-like prefetching can be applied as a hive overload 
of std::for_each, hopefully will have time to do that at some point, and 
will be interesting to see the difference.

Also glad to see the plf:: stuff is separate from the std:: stuff.


/
Minor corrections to the docs:/

"|boost::container::hub| does not conform to the specification of 
|std::hive| in a few aspects:

  * Minimum and maximum block size limits can't be specified and are
    fixed (to 64 in this implementation). |reshape| is not provided as
    it doesn't make sense when block capacity is fixed."


That wording (inadvertently) suggests that min/max can't be fixed and 
equal in a std::hive implementation, which isn't the case. Better phrasing:

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



Likewise the following is slightly ambiguous:

"The |end| iterator is stable and non-transferable, whereas for 
|std::hive| the |end| iterator is invalidated upon any insertion or the 
erasure of the last element (briefly put, |boost::container::hub::end| 
behaves like |std::list::end| whereas |std::hive::end| behaves like 
|std::vector::end|). Technically, this is not a non-conformance but 
rather an extension to the specification of |std::hive|."

I would word it like this:

"The |end| iterator is guaranteed to be stable and non-transferable, 
whereas for |std::hive| the |end| iterator is allowed to invalidate upon 
any insertion or the erasure of the last element (briefly put, 
|boost::container::hub::end| behaves like |std::list::end| whereas 
|std::hive::end| is allowed to behave like either |std::list::end| or 
std::vector::end)."


Though less important, I would change the bit about three-way-comparable 
from 'overhead' to 'overhead for small elements', since for a 6-word type,
an additional 1 word per (6x64) 384-word block makes no measurable 
difference to cache locality , though it does when dealing with 
8->64-bit types.
re: Bookkeeping, in my hive benchmarking with/without the group number 
metadata it made no difference except for splicing, since otherwise the 
numbers are in pragmatic reality pretty much never updated.


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.


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.

Cheers once again-

Matt


On 24/05/2026 5:36 am, Joaquin M López Muñoz via Boost wrote:
> Hi,
>
> I've finished integrating the feedback given at the review of 
> boost::container::hub:
>
> * Branch: 
> https://github.com/joaquintides/hub/tree/feature/review-feedback
> * PR: https://github.com/joaquintides/hub/pull/20
> * Changes:
>   * Fix typos (Matt Borland)
>   * Fix test_api for GCC on darwin (Matt Borland)
>   * Fix iterator de-reference (Matt Borland)
>   * enabled warnings in CI (Matt Borland)
>   * removed undocumented memory() (Andrzej Krzemieński)
>   * typos (Arnaud Becheler)
>   * worked around bogus array bounds warning in GCC (Andrzej 
> Krzemieński/Peter Dimov)
>   * integrated AppVeyor CI (Alexander Grund)
>   * hardened get_iterator (Emil Dotchevski)
>   * Fix B2 + CMake testing (Matt Borland)
>   * replaced visit[_all][_while] with global for_each[_while] (Andrzej 
> Krzemieński)
>   * used aligned new when available and required (Emil Dotchevski)
>   * added exception safety tests and made single-element insertion 
> strongly safe (Emil Dotchevski)
>   * clarified exception guarantees and preconditions of sort (Emil 
> Dotchevski)
>   * s/HFT/high-frequency trading (Peter Turcan)
>   * improved somewhat introductory statement to hub (Peter Turcan, 
> Arnaud Becheler)
>   * made it clear that hub is not a sequence container (Andrzej 
> Krzemieński)
>   * reserved right to change block capacity (64 elements) in the 
> future (Emil Dotchevski)
>   * explained by block size is 64 (Peter Turcan)
>   * improve code comments in tutorial, expanded section on capacity 
> (Peter Turcan, Arnaud Becheler)
>
> Review feedback _not_ included in this version:
>
> * Implement a slot map (Chris Mazakas): this is more for the evolution 
> track
> * Contiguous hub with VirtualAlloc (Chris Mazakas): same
> * Improve perf table presentation (Matt Borland/Dominique Devienne): 
> I'll see to that when the docs are integrated into Boost.Container's
>
> I'd be grateful if you could take a look, comment and maybe warn about 
> feedback I may have overlooked. When Ion gives me the OK, I'll merge 
> and begin working with him on integration into Boost.Container, 
> hopefully in time for Boost 1.92.
>
> Thank you,
>
> Joaquín M López Muñoz
>
> _______________________________________________
> 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/5CZTSS3C2U3BFKJSR3QE6AUMZZMCFTYR/ 
_______________________________________________
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/XC6LJ33FJ45QQ6EYKOQQ6ZMNI3SWE5KT/