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
pizlonator 3 minutes ago [-]
Yes
The only truth is shipping code
Specs are secondary
pmkary 7 minutes ago [-]
I laughed so hard at this....
ch_123 1 hours ago [-]
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.
jdw64 1 hours ago [-]
But looking at this, it seems like something similar happened 12 years ago[1]. Why hasn't it been changed?
The working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.
jdw64 1 hours ago [-]
Is it because the impact of the change is too big? I mean, is that why it's hard to submit a proposal?
tester756 1 hours ago [-]
I'd bet that nobody just cares enough, but idk
ndesaulniers 1 hours ago [-]
Shrug, then write a defect report?
froh 50 minutes ago [-]
on the standard? or the compilers? or both?
hmxrye 1 hours ago [-]
[flagged]
leecommamichael 1 hours ago [-]
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.
tsimionescu 33 minutes ago [-]
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.
jstimpfle 23 minutes ago [-]
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).
leecommamichael 22 minutes ago [-]
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?
t0mpr1c3 31 minutes ago [-]
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.
bee_rider 12 minutes ago [-]
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?
jjmarr 1 hours ago [-]
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.
tadfisher 32 minutes ago [-]
Who is stopping you? Is it an employment concern?
t0mpr1c3 9 minutes ago [-]
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.
feverzsj 1 hours ago [-]
Only if you don't code for living.
wyattblue 30 minutes ago [-]
Consider Nim too!
1 hours ago [-]
Rendered at 20:09:49 GMT+0000 (Coordinated Universal Time) with Vercel.
Standard in the sense of commonly used or supplied
The only truth is shipping code
Specs are secondary
[1]https://cplusplus.github.io/CWG/issues/1555.html
Context: I am a programmer and educator. I am so tired of informing people of these minutiae.
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.
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?
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.