Live data from Hacker News

Neither GCC nor Clang are compliant with standard C++

sebsite.pw

51–60 of 63 posts

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

#51

Earlier quoted context omitted.

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

Apple's Metal is C++ too. Like, actual, you can compile it with plain C++ compiler and a shim header.

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

#53

> 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.

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

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

#54

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

> Every language has to decide if the calling convention is part of the function signature or not

Well, of course it is. If you get the calling convention wrong, then you can't actually reliably call the function. I'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 "pretend that there is only single calling convention that everyone uses" which is apparently somewhat works on platforms that are not 32-bit x86, but only mostly.

> The C++ standard decided to allow this,

Decided to prohibit, actually.

> which actual C++ compiler implementers decided to ignore for whatever reason,

Because it'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.

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

#55

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?

All modern C compilers are written in C++.

C also has dialects.

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

#56

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.

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

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

#57

Earlier quoted context omitted.

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…

It seems like the history of programming languages since the 1980s has mostly been people trying to avoid C++. First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).

I was there, and C++ was all over the place on Windows, OS/2, Mac OS, UNIX/CORBA.

It was FOSS with its set of coding guidelines, that gave C a new wind.

Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.

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

#58
post #48
post #41

Earlier quoted context omitted.

The CUDA/HIP APIs are mostly C-like APIs but are really C++ language extensions. e.g. you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. The GPU kernel code itself needs to be compiled and for CUDA that is done with the proprietary nvcc, which is clang-based. HIP is better because it's an open-source llvm backend/frontend but you'd st…

> you need triple angle brackets when calling a GPU kernel. The compiler turns that into placing the kernel onto the GPU and running it. It all boils down to calling CUDA runtime or driver APIs. Compiler just sprinkles fairly trivial amount of syntactic sugar, and under-the-hood glue code. One can launch GPU kernel from a pure C source file compiled with gcc. > The GPU kernel code itself needs to be compiled and for…

AFAIK PTX compilation is the bit that is not mature in the Rust CUDA ecosystem as well, because it has to be reverse engineered rather than simply translated.

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

#59
post #57

Earlier quoted context omitted.

It seems like the history of programming languages since the 1980s has mostly been people trying to avoid C++. First languages with run-times and dynamic types, and more recently lower levels of abstraction (Go, Rust).

I was there, and C++ was all over the place on Windows, OS/2, Mac OS, UNIX/CORBA. It was FOSS with its set of coding guidelines, that gave C a new wind. Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.

> Languages with runtimes and dynamic types go all the way back to Lisp and Smalltalk.

Java was the 800lb gorilla though, wasn't it? Because it promised portability.

Why did Smalltalk not take off?

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

#60
post #55

Earlier quoted context omitted.

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?

All modern C compilers are written in C++. C also has dialects.

Yes, we switched from C98 to C11 and are about to adopt MISRA C 2023 (with exceptions).
Post reply on HN