3 ms·
Neither GCC nor Clang are compliant with standard C++
- Fudgel 3mo agohttps://archive.md/lBvFq https://archive.md/lBvFq
- jdw64 3mo agoBut 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 https://cplusplus.github.io/CWG/issues/1555.html
- gregdaniels421 3mo agoThe working group said bring us a paper with the exact proposal, I haven't seen an update where someone did.
- jdw64 3mo agoIs it because the impact of the change is too big? I mean, is that why it's hard to submit a proposal?
- ndesaulniers 3mo agoShrug, then write a defect report?
- froh 3mo agoon the standard? or the compilers? or both?
- leecommamichael 3mo agoIf 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.
- feverzsj 3mo agoOnly if you don't code for living.
- deleted 3mo ago[deleted]
- jjmarr 3mo agoUnfortunately 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 3mo agoWho is stopping you? Is it an employment concern?
- t0mpr1c3 3mo agoThis 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.
- edoceo 3mo agoThe Zig group claims that Zig can interop with C based libraries w/o too much work. It's one of the reasons I'm digging into it now. But I don't know anything about CUDA and have only done trivial Zig<=>C tests (like my Zig code working with libpng) so far. Are their claims BS? Is Zig just not mature enough? Something else?
- kloop 3mo agoGive 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
- pmkary 3mo agoI laughed so hard at this....
- pizlonator 3mo agoYes The only truth is shipping code Specs are secondary
- ksec 3mo agoYes. 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.
- dataflow 3mo agoThe blog post basically said exactly this: > IMO the blame here doesn'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.
- hmxrye 3mo ago[flagged]
- ch_123 3mo agoHot 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.
- ameliaquining 3mo agoI 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.
- jamesfinlayson 3mo ago> 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 Yeah 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's pretty good.
- dataflow 3mo ago> gcc and clang can't change their behavior because that would be a breaking ABI change It's an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.
- Joker_vD 3mo agoEh, 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'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.
- deleted 3mo ago[deleted]
- rurban 3mo agoIt's about language *linkages*, not about extern "C" vs C++ linkage. It's about stdcall, cdecl, fastcall, vectorcall, watcall, and other calling conventions, which should be in the type. And they are.