Search this blog

27 March, 2008

C++ is too hard (for me)

I'm going, for the second time, through the book "C++ Coding Standards", a classic C++ book by Alexandrescu and Sutter. "101 Rules, Guidelines and Best Practices". And noone of them is unreasonable.

C++ is a huge language, it does a terrific job of giving to the programmer all the control he needs in order to predict exactly how the machine will execute his code, while still allowing some very high-level constructs to be crafted, extending the language. All of that, still being compatible with C, a.k.a. "the cross-platform assembly language".

Problem is, that to achieve all those three goals together, C++ has an enormous complexity behind it. Books and books were devoted only to tell what NOT to do with C++. Complex static code analyzers has been written to enforce those rules. Where I'm currently working we have more than fifty worldwide coding rules, that can be enriched by other studiowise and projectwise ones, enforced via code reviews and a custom configured static checkers (PC-Lint and Codewizard), and still I can't see them being applied consistently. Nor I've ever seen any source in the game/rendering realm strictly following all the well-known C++ best practices. It's crazy!

Even when you declare a class, there are many things you have to do before actually starting to write any code. The destructor has to be virtual or not? Protected or public? Do you want need to hide copy and assignment? Remeber to mark your single-parameter constructors as explicit. Why? Why do I have to mark my single-parameters contructors as explicit? Why? Why? If I want to declare a conversion operator, I do it, why do I have to use "explicit" to force a behaviour that should be the default one? I'll forget to do it! C++ is too hard for me, there's too much noise...

Bjarne Stroustrup said in an interview: "...Many minor and not-so-minor problems we have discovered over the years cannot be addressed in C++ for compatibility reasons. For example, the declarator syntax is an unnecessary complication—just about any linear notation would be better. Similarly, many defaults are wrong: constructors should not be conversions by default, names should not by default be accessible from other source files, and so on. Not controlling the linker has been a constant source of problems; in particular, implementers seem to delight in providing similar features in incompatible forms..."

Most of those not-so-minor problems are really driving me mad, on some days.

P.S. It could be a very nice idea to provide to your team some templates for the definition of common types, i.e. value types, pure interfaces, static classes, templates, base classes, etc...

P.P.S. Why C++ is considered immutable? Why couldn't we deprecate some old/bad language features? Java does this. You could emit a "deprecated" warning for such features, so people that are not dealing with huge legacy code bases can fix those warnings and turn them to errors, instead of having to rely on external static code checking tools to generate the very same results (because in the end, most of the stuff we enforce with static code checkers are really bad uses of the language that should be forbidden by the language itself)


Anonymous said...

Keep it simple, thats all. Each layer of complexity is a layer of problems and bugs. Do no create a class if you don't really need it, do not follow rules if you don't need them, etc.

DEADC0DE said...

Not following best practices is not an option when you're dealing with code that will probably be reused in ten other projects, possibly worldwide. If you're in a small project then you can be quite sure that some operations will not be ever done, and you can relax your policies (but that still is a coding standard to be enforced, after all). The big problem with C++ is that is so complex that it requires huge coding standards that are really hard to enforce. Never seen them correctly enforced in any project, except for the most used, worldwide-shared libraries (math, memory, etc...).

Unknown said...
This comment has been removed by a blog administrator.