Large-Scale C++ Software Design

My point is, you can write good, readable, performance, large-scale codebases in C++. Note that Carmack wrote his previous engines such as Quake3 in C, and switched to C++ at some point. I think one of the reasons was that as their programming team size grew from 5 to 50 at id, C++ started making more sense for them. If you look at a book like "Large Scale C++ Software Design", the subset of C++ it uses is about the subset that I think makes sense in practice, roughly C with classes. To be fair, I think that was the language subset that actually worked in compilers at that time.

Irrespective, I don't doubt that C is a valid and perhaps better choice for writing an OS kernel. There's less abstraction in C, and you have to worry less about making sure you don't use a language feature of C++ that has a hidden cost.

https://github.com/mtrencseni/quake3

The book I mentioned, "Large Scale C++ Software Design":

http://www.amazon.com/Large-Scale-Software-Design-John-Lakos...

dkarl · 2011-02-27 · Original thread

In fact, no one uses straight C++ to make anything, in real world everyone starts by sub-setting C++ into something "safer" and then adding back the fundamental missing features (i.e. memory management, serialization, reflection and so on) via libraries, macros or other trickery (i.e. code to code transformers, code generators or parsers and so on), so really the C++ we use is not a standard, but a studio specific version of the language.

I really don't understand this at all. He seems to be saying that using "straight C++" would mean using the worst parts of the language in the worst ways, but not taking advantage of the features that make C++ usable. If he really thinks everyone uses macros, code generators, or code transformers to do real-world C++, then he's wrong. I've been using C++ professionally for almost ten years now, and I've never seen anything like that except: a few legacy macro tricks that we easily replaced with better, non-macro techniques; and Qt's preprocessor, which we never actually used in production code.

Style points for C++ have been rehashed endlessly. "C++ Coding Standards" is pretty good IIRC: http://www.amazon.com/Coding-Standards-Rules-Guidelines-Prac...

For gaming and embedded software, you will need further rules for performance. I'm not sure why this is a ding on C++. Doesn't any reasonably powerful language have performance pitfalls? Don't use CLOS in your embedded systems, folks.

C++ as a medium for our art looks more like statuary marble than modeling clay: it requires a team of muscular stone cutters under the guidance of a genius in order to produce some amazing sculptures. And once a given idea has been translated into the stone, you hardy can change it without re-sculpting most of it or having to work in the constraints that the shape it currently has impose on you.

This is only true if your system is badly factored or if you are averse to recompiling. "Ahhh, arrgh, no, I refuse to change the interface of this fundamental class referenced by every other object in the system because the next compile-link cycle will take ten minutes! I'll leave it crappy for the rest of eternity just so I don't have to wait ten minutes for a compile, or because my approach to changing this extremely fundamental class is to keep making haphazard changes to its interface until my code finally works, so my ten or twelve compile-link cycles will cumulatively take almost two hours." Fine, we'll have an adult make the change instead.

Now I'm really not suggesting that it doesn't suck when you have to wait ten minutes to recompile your system when you change an interface that every other source file in your system includes, but I hope recompilation time is not the weightiest consideration in that case.

It's not a coincidence that the more a language is dynamic, the less need there is for fancy debugging tools. Who needs a watch window indeed, if I can just add on the fly a widget on screen that graphs the value of a given variable?

This is a legitimate complaint. Building instrumentation into a C++ system is a pain in the ass, and it will never be as powerful as in a language with introspection.

Well, the art of sculpting in C++, the art of design, becomes really the art of subdividing our sculpture in pieces, the real design challenge is all about how to cut or work into pieces. Too many of them and the sculpture will be a fragile and ugly mess (translation: craptastically slow OOP shit). Too little and we loose flexibility.

As far as I can tell, the point here is that if C++ was a better language, bad design wouldn't be a problem. If it took C++ to drive him to consider OO design principles, I'd hate to see the code he wrote in other OO languages. Also, decomposition is not the only consideration. There are cross-cutting concerns such as memory management, logging, and instrumentation.

The design principles at the end of the post are better and more comprehensively covered by "Large-Scale C++ Software Design": http://www.amazon.com/Large-Scale-Software-Design-John-Lakos... Some of the language points in that book reflect the immaturity of C++ implementations when the book was written, but the design guidelines are still relevant.

In general, it's very hard to say anything original about C++. Practitioners and proponents of C++ are much more aware of its limitations than its detractors realize. Also, this may come as a shock to the web generation, but C++ is a topic that is very well covered by available books. Just as you might browse through a few relevant blogs to see if someone else has already made the same point you were about to make, with C++ you should do the same with the highly-regarded books.

ISBN: 0201633620