That is very useful information to know, thank you, I feel a lot
better knowing we are making progress like that. I couldn't find more
aggressive settings for gcc/clang that changed its optimization
budget. I might be wrong about that too, you did just school me on the
effects of -std.

That was just a contrived example, sorry. (Personally,
I think a hardware cache visualizer was the best tool I ever used for
optimization, but I haven't seen one of those since the PS2.)

I actually wrote my own library for exactly that reason. I dislike
templates enough that I ended up writing a ton of template code just
to prove you didn't need so many of them. You don't need to rewrite
the standard for me, I already went down that road.

https://github.com/whatchamacallem/hatchlingplatform

Thank for the info. I'll try to be more open minded about the standard
template library.

On Sun, Aug 24, 2025 at 9:26 PM Jan Schultke <janschultke_at_[hidden]> wrote:
>
> > So, my first proposal is to have a template library that can operate
> > using pointers and arrays without extra templated abstraction layers.
> > Then the compiler does a better job, your compiler errors are nice and
> > clean and the debugger is a relative joy to use. And when it comes to
> > safety, the clang sanitizers can be used to make raw pointers just as
> > safe as iterators these days.
>
> We already have that in some sense. You can pass pointers directly
> into standard library algorithms and disable every possible assertion
> that would have run by default.
>
> Also, I'm not sure what settings you've used to get that "bad"
> assembly output, but both GCC and Clang with -O3 and -std=c++23 output
>
> "example1()":
> mov edx, 3
> mov esi, 7
> mov edi, OFFSET FLAT:.LC0
> xor eax, eax
> jmp "printf"
>
> ... for the std::sort case. https://godbolt.org/z/EvP6szbWd I was able
> to get the bad output you're describing only without a -std flag.
>
> Even if it wasn't possible to get this "good" output here, eyeballing
> performance by looking at assembly is a terrible habit. You should
> actually benchmark the code instead of cherry-picking a bad assembly
> snippet and declaring we have to overhaul the standard library so you
> won't get that bad snippet again. Most of these obvious bad codegens
> can likely be resolved by submitting a bug report or better yet,
> contributing to your standard library of choice.
>
> > If that seems unnecessary because the compiler should be up to the
> > task at hand then please consider my second proposal. Why don't we
> > have a way to convince the compiler to do what we are telling everyone
> > it does? I have seen a professionally written C++ codebase spend 3% of
> > its time inside std::vector::operator[] with all optimizations turned
> > on. (This is why the standard library gets banned from real-time
> > embedded projects.) If we required support for -O9 and told everyone
> > they may have to let the compiler run overnight then at least all this
> > talk about what is possible with compile time evaluation would be less
> > deceptive.
>
> You can manually specify more aggressive optimizations such as
> increased inlining threshold for various compilers. What you're
> describing seems like you want additional compiler flags, or maybe
> just need to read your compiler's manual. There is nothing to propose
> here.