Live data from Hacker News

Neither GCC nor Clang are compliant with standard C++

sebsite.pw

21–30 of 63 posts

Re: Neither GCC nor Clang are compliant with standard C++

#21

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.

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?

Re: Neither GCC nor Clang are compliant with standard C++

#22
post #13

Earlier quoted context omitted.

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.

Re: Neither GCC nor Clang are compliant with standard C++

#23
post #7

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

I laughed so hard at this....

Re: Neither GCC nor Clang are compliant with standard C++

#24
post #7

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

The only truth is shipping code

Specs are secondary

Re: Neither GCC nor Clang are compliant with standard C++

#25

Earlier quoted context omitted.

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 actua…

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.

Re: Neither GCC nor Clang are compliant with standard C++

#26

Earlier quoted context omitted.

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?

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.

Re: Neither GCC nor Clang are compliant with standard C++

#27
post #7

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.

Re: Neither GCC nor Clang are compliant with standard C++

#28
post #12

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 yo…

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.

Re: Neither GCC nor Clang are compliant with standard C++

#29

Earlier quoted context omitted.

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 inheritance. We barely even use templates. We try to avoid allocating on the heap. The code is mostly imperative.

Since 2011, a lot of new language features have been introduced. The ones we use are things like smart pointers (that improve lifetime management) and some tweaks for better type safety.

It is said that moden C++ enables a functional programming style. I have never actually seen anybody code that way (it would be hell to write and worse to read) 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 enforce a consistent style.

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

Re: Neither GCC nor Clang are compliant with standard C++

#30

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.

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.

[deleted]
Post reply on HN