Hacker News Reader

Comment by holowoodman | Hacker News Reader

There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.

View on HN

Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.

There's nothing inherent about C++ that makes it more suited than Rust for game engines though, Rust supports careful management of memory too. Of course, nothing besides inertia (i.e. Libs, existing code, etc.). And that of course is more than big enough of a reason to stick with it.

Rust supports careful management of memory at the expense of unsafety, at which point that particular area of the code offers no benefit over C/C++, let alone value in a rewrite. There is no type system for reinterpreting bits of memory.

And for the safe parts, the posts that I've read from people who have spent a non-trivial amount of effort with the language do not paint a clear picture either on whether there was really a benefit to the language overall.

So to say that "the world has moved on" in light of all of this is pure hubris.

C++ is widely used in embedded. Most compilers support it. Usually you turn some things off (e.g. -fno-rtti, -fno-exceptions) and try to stick to some sane subset of the ++.

C++ in embedded is basically C with classes. It is a nice simple language and often doesn't even include templates (or if it does they are very simple data structures that are not even heap allocated).

C++ as C with classes is a pretty good language!

haha, fun fact - Unity is C++ code base. You need to look deeper

It is a pitty that

- GCC switched from C to C++

- CUDA switched from C to C++

But I can understand the decision, and at that time , C++ frontend features and libs were a little bit less horrible.

It's a pity?

Please explain in detail how alternatives would have worked better for GCC and CUDA. Also, if you could share some historical context about how those alternatives could realistically have been implemented at the time, that would be helpful too.

I love to hear all the "would've" and "should've" scenarios.

Last time I checked, MSVC don't want to implement C99/newer and instead focus on C++.

To be fair, MSVC has the most C99 stuffs. What is mainly missing for porting (my) programs is the native complex number. But we have Intel compiler for free on Windows, which is fully compatible with the C/C++ standard and produces faster binaries.

The C++ frontend of MSVC handles (the common) compiler-specific language extensions differently than the other compilers. Besides, its pre-processor behaves differently too. It is now good that there is a clang frontend for MSVC.

Reply on news.ycombinator.com