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

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

Yes

The only truth is shipping code

Specs are secondary

I laughed so hard at this....

Hot take: I feel like a lot of the original value of language standards was to unite multiple proprietary implementations of compilers/runtimes/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.

I half-agree with this. People occasionally argue that, e.g., Rust won't be suitable for production use until it has two fully independent mature implementations, and I consider this a silly requirement that doesn't serve any real purpose. On the other hand, once multiple separate implementations are already in widespread use, there'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's always possible that the standardization body doesn't in practice do a very good job, as seems to maybe be the case with the C++ committee. Also, I'm only talking here about technical considerations, not governance ones.

But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn't it been changed?

[1]https://cplusplus.github.io/CWG/issues/1555.html

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

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

I'd bet that nobody just cares enough, but idk

Shrug, then write a defect report?

on the standard? or the compilers? or both?

If you'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.

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's just a bug, of which, again, you'll find many others if you actually do systems programming.

I'll also note that "Odin, Rust, Zig" 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't even have a Wikipedia page. Zig is still pre-1.0 and often makes breaking changes to core libraries.

To be fair, Odin _had_ a Wikipedia page and it has been removed because of... people with whatever interests. But I'm still agreeing with your general point. I use C/C++ because it seems to be the least friction option to me overall, and I don'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'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's kind of a mashup of recent pop-culture things. I'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?

Engineering details matter, a lot.

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

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?

I've been writing C++ for embedded systems the past year or two.

We use a very conservative subset of C++, almost like C with classes. The code is mostly imperative. We barely even use templates. We try to avoid allocating on the heap.

Since 2011, a lot of new language features have been introduced. It is said that they enable a functional programming style. I have never actually seen anybody use C++ that way, but that could just be the niche I'm in.

What is undeniable is that C++ is so complex and has so many features that you have to choose a subset of the language to have a consistent style.

Also a lot of the STL (standard library functions) are deprecated in one way or another, which is a real minefield.

The dialects issue is why I avoid interviewing in C++, because inevitably it turns out the interviewer has some weird view of what "C++" is and doesn't realize it. Years ago I had an interview in "C++14" that required std::optional (C++17) as implemented by a C++14 compiler with only experimental, nonstandard support. In another case, an interviewer on the LLVM team vehemently disagreed with me that you could legally implement std::atomic types with mutexes, as I was going over a story about fixing issues in an awful stdlib that implemented them with mutexes.

This kind of thing doesn't happen when I interview in other languages.

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

Who is stopping you? Is it an employment concern?

This question strikes me as somewhat obtuse, but I will attempt an answer:

NVIDIA and AMD.

These are only two GPU manufacturers of any significance. (Intel is also a player, but not a major one.)

They supply SDKs (drivers and libraries required for software development) for their products that support C and C++ and precious little else.

There have been attempts to reverse engineer the toolchains in Rust but as I understand it they are not yet mature.

Only if you don't code for living.

Consider Nim too!