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