21 Jul 2010 ncm   » (Master)

(Following up from redi about Avery's anti-C++ rant and my earlier response...) On re-examination, I find Avery is wrong in practically every detail, most probably because he started out and still lives in the world before there was a Standard C++.

Redi already noted that the Return Value Optimization (RVO) doesn't depend on inlining, and that Avery's example doesn't depend on the RVO anyway. I will add that RVO is implemented in every extant compiler, so you should think of it as a regular language feature.

Avery complains vaguely about C++ exceptions, but C++ is the only language where exceptions actually work. That's because C++ is the only language that has real destructors. Other languages need a "finally" construct, which obliterates most of the potential benefit of exceptions.

Everything Avery complains about in std::string is a feature; i.e. it has 99 problems, but Avery's ain't them. If you find yourself making a string class, you're wasting somebody's time. If your function would be just as happy with a const char*, then make it take a const char*. I don't make my own string types; I use either std::string or char*, and one or the other always does the job.

Avery's complaints about function pointers are just weird. In most places where you would have used a function pointer in C, you want a virtual function in C++. That's close to the only place where virtual functions are actually useful (which makes it criminally idiotic that virtual functions are the default in Java, but I digress). Most people don't find it immediately obvious how virtual functions fill in for function pointers without looking at actual examples. Now that you know, though, you can look for yourself.

So, if in all of Avery's examples he's wrong, where is he right? He's right that C++ code cannot be made as pretty as code in a slow language, and that it's a mistake to try. C++ code is always going to look kind of clunky. The knack is to know which kinds of clunkiness are essential, and which are your fault because you didn't think clearly about what you are doing. If you find yourself overloading operator[] or fooling around with exotic function pointers, it's probably the latter. Coding good C++ is a lot like chess; ask yourself, "does this line help solve an actual problem?" If not, it's likely to be procrastination, or over-engineering, or wankage. It's not to C++'s credit that you have to ask yourself that, but no language deserves the blame for your own dilatory impulses.

What sucks most is that there is no useful and pretty language as powerful as C++, and none being worked on, so those of us doing hard things will depend on C++ indefinitely. Other, slow languages will come and go and be used for easy problems, as Bram's Law predicts.

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!