Date: Thu, 9 Apr 2026 16:10:13 -0400
On Thu, Apr 9, 2026 at 1:53 PM Muneem via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> In short answer: The programmers dosent know what book keeping actually works for that specific hardware.
>
> Detailed answer:
>
> 1. The programmers dosent know what book keeping actually works for that specific hardware. Programs compiled for extremely old legacy computer's don't have that much space to spare to get a cache Friendly design. Not to mention that there are many totally different computer that a programmer might not have even heard of, like the intel Xeon CPUs.
> 2. As shown in my example, I don't know if the N space overhead is better or should I opt to a recursive N-1 call to a base class that handles the rest while inheriting from that. Why? Because I don't know if the optimizer can optimize such recursion it out breaking ABI's or something, like I don't know that for every computer in the world and don't want to.
> 3. Dont rely on speed that is only there under "some circumstances".
Working C++ programmers do that as a matter of course.
> 4. This brings me back to writing Painful C code. Like the reason that I or anyone else moves from C to c++ is because C forces me to rewrite flat maps and what not. Even then my implementation is outperformed by the STL because I can't use inline assembly without spending a year learning each target architecture. A implementation like MSCV or Clang is.
Here's the thing though: for the case where "my implementation is
outperformed by the STL," there is *clear evidence* of this
outperformance. It's not some hypothetical statement made with vague
references to other things that are slow. In the case of flat_map, you
can point to clear evidence of what the performance was before, what
the performance is after, and specific mechanisms that offer that
performance. You can look at the implementations of the types, the
quality of the compiled code, etc.
>From what I've been able to gather from this extremely disjointed
conversation, you do not have specific evidence of an actual
performance problem that actual C++ programs have which compilers are
otherwise incapable of solving and where programmers can't just
develop better abstractions within the language to fix.
Your "proposal" seems to be founded entirely on the idea that there is
some performance that programs are leaving on the table because they
cannot express certain things directly to the compiler, and that your
proposed changes will repair this deficiency. I've yet to see evidence
for either of these propositions which was not quickly debunked.
Merely saying something like "it'll be like flat_map but for
polymorphism!" doesn't prove anything.
Oh, and one more thing: notice how, in the above text, I have put
empty space between each paragraph? That makes it *much* easier to
read. Please try doing that yourself. And you don't need to put stuff
into numbered lists; that doesn't help legibility.
<std-proposals_at_[hidden]> wrote:
>
> In short answer: The programmers dosent know what book keeping actually works for that specific hardware.
>
> Detailed answer:
>
> 1. The programmers dosent know what book keeping actually works for that specific hardware. Programs compiled for extremely old legacy computer's don't have that much space to spare to get a cache Friendly design. Not to mention that there are many totally different computer that a programmer might not have even heard of, like the intel Xeon CPUs.
> 2. As shown in my example, I don't know if the N space overhead is better or should I opt to a recursive N-1 call to a base class that handles the rest while inheriting from that. Why? Because I don't know if the optimizer can optimize such recursion it out breaking ABI's or something, like I don't know that for every computer in the world and don't want to.
> 3. Dont rely on speed that is only there under "some circumstances".
Working C++ programmers do that as a matter of course.
> 4. This brings me back to writing Painful C code. Like the reason that I or anyone else moves from C to c++ is because C forces me to rewrite flat maps and what not. Even then my implementation is outperformed by the STL because I can't use inline assembly without spending a year learning each target architecture. A implementation like MSCV or Clang is.
Here's the thing though: for the case where "my implementation is
outperformed by the STL," there is *clear evidence* of this
outperformance. It's not some hypothetical statement made with vague
references to other things that are slow. In the case of flat_map, you
can point to clear evidence of what the performance was before, what
the performance is after, and specific mechanisms that offer that
performance. You can look at the implementations of the types, the
quality of the compiled code, etc.
>From what I've been able to gather from this extremely disjointed
conversation, you do not have specific evidence of an actual
performance problem that actual C++ programs have which compilers are
otherwise incapable of solving and where programmers can't just
develop better abstractions within the language to fix.
Your "proposal" seems to be founded entirely on the idea that there is
some performance that programs are leaving on the table because they
cannot express certain things directly to the compiler, and that your
proposed changes will repair this deficiency. I've yet to see evidence
for either of these propositions which was not quickly debunked.
Merely saying something like "it'll be like flat_map but for
polymorphism!" doesn't prove anything.
Oh, and one more thing: notice how, in the above text, I have put
empty space between each paragraph? That makes it *much* easier to
read. Please try doing that yourself. And you don't need to put stuff
into numbered lists; that doesn't help legibility.
Received on 2026-04-09 20:10:28