John Carmack's Comments On C/C++

[Azimuth]

Part of the whole "fad" part of 'D'. I should check back into CLAY. From a language perspective that was looking pretty decent. Not just another same old same old object inheritance thing, but an attempt at some orthogonality and simplicity. The biggest strike was missing "const".

Have you checked out the Rust programming language by Mozilla (rust-lang.org)? It it a systems programming language with many safety features (no null pointers, const/immutability by default, built on top of the LLVM, no GC if you don't need it, etc.)

[dnebdal]

As I'm old school (and embedded developer) I still use C. But even with C, my coding rules ban me from using some features of the language. The thing is that C++ has many features that leave a program indecipherable, like operator overloading. Yes, it is a powerful tool, yet it is often misused and makes the code hard to understand.
Being a C programmer, I've always liked Java for it's simplicity. But then again, Java developers tend to abuse OOP paradignms just for the sake of having beautiful object model design. If I had to ask something to Java is unsafe contexts and an easier JNI, just like C# has them.
Anyway, If you write C code, you get a better glimpse of what machine code the compiler may generate.

Just adding a native unsigned 8-bit int type to java would make me happy.

[erendorn]

The c++ benefits does not compensate for its technical cost. Then, better stick to C.

The c++ benefits does not compensate for its technical cost for you. What you wrote is like saying "Don't use competition skis, their benefits do not compensate for the difficulty to handle them". Certainly true for a beginner, certainly false for a competitor.
I personally would miss exceptions, templates and polymorphism too much.

[sylware]

my opinion

The c++ benefits does not compensate for its technical cost. Then, better stick to C.

[bnolsen]

And much of the standard library relies on GC, so what then, roll your own to be sure?

Part of the whole "fad" part of 'D'. I should check back into CLAY. From a language perspective that was looking pretty decent. Not just another same old same old object inheritance thing, but an attempt at some orthogonality and simplicity. The biggest strike was missing "const".

Btw this is a topic about john carmack and c++. How did this turn into a discussion on 'D'? Sometimes I wonder about astroturfing...

[joe_gunner]

That's why D has an option to turn it off.

And much of the standard library relies on GC, so what then, roll your own to be sure?

[joe_gunner]

D is far easier to read and write than C++.
At beginning the language had some important bug that is the normal workflow for anything in informatic. Now the language is stable and for new code is better to start with D. Try it now

I don't think it's easier to read, templates yes, the rest no. Much of the recent code ive seen recently seems to have diverged from C syntax which to me is the most readable.

[bnolsen]

Syntax being easy to read, expressive and flexible seems like it's the most important thing.
(I notice that with the << it's easier to read, produces smaller code and is (less error prone?) shorter than printf.)
(The use of the %s, %d specifiers has an issue since the type specification seems to conflict with the DRY principle of software engineering. )

Ugh.. iostreams is the absolute worst part of the whole standard c++ libraries. It's slow, full of thread locks (due to locale being attached to the binary streambuf base class), bad design with "<<" (horrible for translation grammar).

I'm not a huge fan of "auto" except in very limited cases. It looks like a vehicle for generating unmaintainable/unreadable code. Someone looking at this stuff dry has not idea what datatypes are contained in those variables. I'll limit "auto" for use with those ugly iterator declarations, thank you.

[phred14]

As I read TFA and the comments here, a slight paraphrase comes to mind... "Those who do not understand/remember classical structured programming are doomed to reinvent it - poorly."

Back in the day, I did a pile of non-trivial code in both Pascal and Modula-2. I never did a device driver, but I did do a re-entrant interrupt handler as a DOS TSR way, way back. I interfaced to C graphics libraries, (SWIG didn't exist, back then, so I wrote .defs by hand.) both read and wrote legacy binary data of multiple types.

Both languages were criticized for "not being able to do anything useful - only writing toy software," but I had quite a bit of useful code written in both. With Modula-2 another common criticism was that it didn't have a good collection of libraries. SWIG didn't exist back then, but I think it would render that issue moot, today. Both languages were also extended to become useful, and that is a valid criticism, though much less so with Modula-2 than with Pascal.

The more common criticism against both was about "programming in a strait-jacket." But here we see Carmack voluntarily donning that strait-jacket in the name of readability and, I presume, reliability, debuggability, etc. What's more, since C/C++ don't directly have the strait-jacket features, he's working hard to get that stuff back with templates. In that same light, look at the fact that we're still seeing software bugs that Pascal/Modula-2 never would have let us make. Obviously there would still be bugs, and no doubt new categories of bugs, but we're still fighting entirely too many trivial bugs, even now.

To be fair, neither Pascal nor Modula-2 were object-oriented without heavy extensions. I did do object-oriented-style programming with Modula-2, just like it can be done with C, but it's nicer when the language helps you. There is another variant called Modula-3 that is object oriented, but I haven't played with it.

Then again, there are Oberon and Oberon-2. Those were Wirth's ventures into OO. The former was more of a teaching/experimental language, like Pascal, while the latter was meant to be practical. I hung out on the Oberon-2 Usenet group for a while. One of those "simplifications" was taking away variant records and the "packed" directive, which was my Swiss-army-knife for accessing legacy binary data. I brought this up on the list, asking how the heck I was supposed to work with legacy binary data. Their answer was to get all of those legacy applications re-coded into Oberon-2. That was about the time I quite following the language.

About that time I shifted platforms to Linux, and never really picked up doing my own compiled code since, past "./config ; make ; make install". I do mostly Python these days. (and still wish for "var" and "const", so I know exactly how things are being passed)

[movieman]

the gc from d is not suitable for AAA games.

Garbage collection is braindead. It's supposed to prevent programmers screwing up memory allocation and deallocation, but just gives them a whole new set of ways to screw up instead while sucking up performance and RAM.

And if you're using STL in C++ you probably have to write 'new' or 'delete' about once a year.