Re: [hub] Post-review version ready

Joaquin M López Muñoz via Boost <[email protected]> Fri, 29 May 2026 19:27:14 +0200
Newsgroups gmane.comp.lib.boost.devel
Message-ID <[email protected]>
El 29/05/2026 a las 2:02, Matt Bentley escribió:
>
>
> On 29/05/2026 6:35 am, Joaquin M López Muñoz wrote:
>> El 28/05/2026 a las 3:16, Matthew Bentley escribió:
>>>
>>> [...]
>>> 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.
>>>
>> I've checked locally in the past with and without forced inlining: 
>> GCC and Clang do not seem to be really affected, but MSVC benefits a 
>> bit. We observed a similar behavior when working with 
>> boost::unordered_flat_map, my impression is that MSVC has a very low 
>> inlining budget. I may revisit this again anyway, never hurts to 
>> double check.
>>
>> Thank you,
>>
>> Joaquín M López Muñoz
>
>
> Yes and to be fair it was a long time ago when I checked this, and 
> compilers change their policies all the time :/
>
> You might want to look at my overloads for distance/advance - they all 
> follow the same pattern as range-erase (between O(1) and O(n), 
> typically O(log n)). You'd have to use ADL of course.
>
Yes, hub could do something similar. The bad thing about _not_ being a 
container in the stdlib is that you must rely on the user doing ADL for 
it, as you mention.

On a somewhat related note, Ion has been experimenting with efficient 
algorithms for segmented iterators:

https://boostedcpp.net/2026/05/18/neoclassical-c-segmented-iterators-revisited-1/

Some stdlib implementations like libc++ use these techniques 
_internally_, which negates the potential benefits to external 
libraries. It'd be terrific if Ion could eventually work out a std 
proposal for this, but I don't know if this is his appetite.

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/HHA5M2TQHBWEQLFT5EM3OZY3KRPLBIHZ/