Yes. And Hasn&#x27;t this always been the case? Before GCC and Clang took over everything there were plenty of C &#x2F; C++ compilers from Intel, Visual C++ etc.

The blog post basically said exactly this:&gt; IMO the blame here doesn&#x27;t lie on gcc or clang; it lies on the standard. that is, the standard is wrong and should be updated to make this implementation-defined.

YesThe only truth is shipping codeSpecs are secondary

Give how default gcc and clang are, along with the recommendation to update the standard instead of gcc and clang, it sounds like the standard is noncompliant with standard C++Standard in the sense of commonly used or supplied

<a href="https:&#x2F;&#x2F;archive.md&#x2F;lBvFq" rel="nofollow">https:&#x2F;&#x2F;archive.md&#x2F;lBvFq</a>

Eh, both are about the same? With the source-level API changes, you can patch the source code or, you know, just keep using the already existing binaries, or keep using the old compilers. But if you break ABI, you can&#x27;t keep using those already existing binaries, you need to start upgrading in bulk. Using the new compilers. That also probably have some source-level API changes. Oh dear.

&gt; gcc and clang can&#x27;t change their behavior because that would be a breaking ABI changeIt&#x27;s an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.

&gt; On the other hand, once multiple separate implementations are already in widespread use, there&#x27;s immense value in working out a least common denominator of language features and standard library APIs that work everywhereYeah this was what I thought. I remember Valve Software wrote a paper about cross platform development and said it was useful compiling with Visual C++ and gcc to shake out any iffy syntax that worked in one but not the other. Of course with performance-critical code and code that needs to run on consoles as well there will always be platform-specific stuff, but if you can get 99% of the code working across multiple compilers that&#x27;s pretty good.

I half-agree with this. People occasionally argue that, e.g., Rust won&#x27;t be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn&#x27;t serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there&#x27;s immense value in working out a least common denominator of language features and standard library APIs that work everywhere, so that library authors can write portable code that users of any implementation can depend on.Of course, it&#x27;s always possible that the standardization body doesn&#x27;t in practice do a very good job, as seems to maybe be the case with the C++ committee. Also, I&#x27;m only talking here about technical considerations, not governance ones.

Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers&#x2F;runtimes&#x2F;etc. from different vendors, each of which had incentives to add non standard features to attract customers and keep them locked in. This has been significantly diminished in the last decade or two now that most languages have high quality open source implementations - now you can simply port your compiler of choice to the platform you need.

Is it because the impact of the change is too big? I mean, is that why it&#x27;s hard to submit a proposal?

The working group said bring us a paper with the exact proposal, I haven&#x27;t seen an update where someone did.

But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn&#x27;t it been changed?[1]<a href="https:&#x2F;&#x2F;cplusplus.github.io&#x2F;CWG&#x2F;issues&#x2F;1555.html" rel="nofollow">https:&#x2F;&#x2F;cplusplus.github.io&#x2F;CWG&#x2F;issues&#x2F;1555.html</a>

On embedded, your fight totally is against language and runtime. Since you cannot gave conformant freestanding C++ without exceptions, rtti and most of STL, &quot;using c++&quot; on embedded always turns into &quot;using gcc&quot; or &quot;using clang&quot; — their mutually compatible, but completely standards non-conformant extensions that make writing for embedded reasonable to even attempt. At that point, is the language still c++?Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.

These are legitimate complaints, and I meant for &quot;if you can afford it&quot; to do a lot of lifting in my first comment.

I&#x27;ve tried it, and no. Honestly C++ gets so many complaints partially because so many people use it. It deserves a lot of it.I just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC&#x27;s DMA&#x2F;TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?What&#x27;s nice about C++ is that your fight isn&#x27;t against the language and runtime. They don&#x27;t care what your situation is. They&#x27;ll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.Yes Rust and its libraries are getting better. But so&#x27;s C++.

&gt; Every language has to decide if the calling convention is part of the function signature or notWell, of course it is. If you get the calling convention wrong, then you can&#x27;t actually reliably call the function. I&#x27;ve seen this in e.g. Win32 — pass the function with the wrong calling convention as your callback, and it will dutifully thrash your stack.The only other option is &quot;pretend that there is only single calling convention that everyone uses&quot; which is apparently somewhat works on platforms that are not 32-bit x86, but only mostly.&gt; The C++ standard decided to allow this,Decided to prohibit, actually.&gt; which actual C++ compiler implementers decided to ignore for whatever reason,Because it&#x27;s UB anyway so why bother detecting it, and it mostly works most of the time when people use it, so again, why bother prohibiting it? No promises on keeping things working in perpetuity, of course.

To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I&#x27;m still agreeing with your general point. I use C&#x2F;C++ because it seems to be the least friction option to me overall, and I don&#x27;t want to deal with language but simply focus on my actual compute problem. (Given that, I spend an unreasonable amount of time in silly fights about language).

I&#x27;m talking about design flaws, not engineering details. I would appreciate if you would respond in spirit. I do think the list I gave is odd, and it is so because it&#x27;s kind of a mashup of recent pop-culture things. I&#x27;m literally just appealing to people to attempt to use something designed with the benefit of 50 years of hindsight. Why am I being downvoted?

Systems programming is very much about minutiae, to a great extent. And this particular detail will affect any systems language, one way or another. Every language has to decide if the calling convention is part of the function signature or not, and every systems language then has to decide whether it allows C functions with the same name as native functions or not. The C++ standard decided to allow this, which actual C++ compiler implementers decided to ignore for whatever reason, but that&#x27;s just a bug, of which, again, you&#x27;ll find many others if you actually do systems programming.I&#x27;ll also note that &quot;Odin, Rust, Zig&quot; is a weird enumeration - neither Zig nor Odin are anywhere near being a realistic option for a new complete system. Odin is so obscure it doesn&#x27;t even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.

C will outlive all of us.C++… I don’t know it well. But I’ve heard there are a lot of different dialects, to the point where it is possible that two C++ programmers might be writing in essentially different languages. How “old” is the language, in that case?

While both C and Rust compiler infrastructure used by Linux drivers is written in C++.

Lindy&#x27;s Law says C will be around longer than any of that lot. Although I wouldn&#x27;t bet against Rust now that it&#x27;s used for Linux drivers.

Who is stopping you? Is it an employment concern?

Unfortunately I&#x27;m a GPU programmer. C++-based CUDA&#x2F;HIP is still the standard regardless of how much people would rather use Rust to program GPUs.

Only if you don&#x27;t code for living.

If you&#x27;re starting a new project and can afford it, please for the love of the children, use a different systems language. In so many ways Odin, Rust, Zig, whatever are better. There will be growing pains with respect to collective knowledge and performance, but they are surmountable.Context: I am a programmer and educator. I am so tired of informing people of these minutiae.

on the standard? or the compilers? or both?

Neither GCC nor Clang are compliant with standard C++