ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
52% Positive
Analyzed from 1887 words in the discussion.
Trending Topics
#language#standard#rust#code#systems#lot#different#don#actually#gcc
Discussion (52 Comments)Read Original on HackerNews
Standard in the sense of commonly used or supplied
> 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.
The only truth is shipping code
Specs are secondary
It's an API change. Breaking source code is generally an even bigger deal than breaking binary compatibility.
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.
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.
[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 just finished my work on a 2.5 yr rust project that was very low-level. The problems I had with it were that the language and library designs will always be behind the current state of the art in performance. Hardware and systems APIs change quickly, and they can shift the optimal design decisions easily for different workloads. E.g. chiplets on your CPUs can change where you want to put your io_urings, their workers, and any relevant sq_poll threads. Your NIC's DMA/TLS facilities can change your memory pool policies - do you want zero-copy APIs, or is the copy required anyways because of all the CPU-local work you have to do? Do you preallocate and feed giant buffers to register with the io_uring, or do you need to share your memory pool with the rest of the application? Do you use a single mutex for the pool, a hierarchy between thread-local and global? Do you also use a chiplet-local allocator?
What's nice about C++ is that your fight isn't against the language and runtime. They don't care what your situation is. They'll work. You do have to assemble it, and other languages make some assemblies a lot easier to do.
Yes Rust and its libraries are getting better. But so's C++.
Meanwhile, both rust and zig will gladly compile your standalone function into standalone binary.
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.
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.
Now, if we were to be talking about memory safety, that would be a very different discussion. But you only mentioned "minutia" as the problem with C and C++, so I don't even know what you were actually meaning to talk about.
Furthermore, in relation to those 50 years of hindsight - Rust and Zig actually go in very different directions on fixing C or C++'s flaws, so it seems that people actually learned very different lessons in those 50 years - and I believe neither agrees with the lessons learned by the other.
No, because the entire distinction falls apart pretty quickly into "shit I like to discuss and care about" and "shit I don't care about and don't want to talk about."
Systems programming lives and dies by the details you want to ignore. The economics of large software production are mildly affected by language design. But weaknesses there are easily overcome with engineering practices and additional tooling. Almost every complaint about C++ safety I've ever heard hasn't been a problem for me for decades, because I know what libraries, practices, and tools solve those problems. But I've yet to work with another language - and I've programmed in a shit-ton of languages - that gets out of the way as well as C++ when I want to systems-program. Even C. C is strictly lower level, but its lack of abstraction facilities gets in the way more than some of the modern numerical-type-safety stuff of C++ does.
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?
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.
C also has dialects.
This kind of thing doesn't happen when I interview in other languages.
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.