Re: [hub] Post-review version ready

Ugh, I meant "post-erasure iteration results" :|

On 27/05/2026 12:29 pm, Matt Bentley wrote:
>
> 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/JOQXRSQ4OCYIK7Y5IZSX5KLLUE5VWSRE/