Archive
Yet Another Nit
Programming in C++, I “prefer” composition over inheritance. Thus, for that reason alone, I’d use “ComposedLookupTable” over “InheritedLookupTable” every time:
In addition, since (on purpose) no STL container has a virtual destructor, I’d never even consider inheriting from one – even though those who do would never try to write this monstrosity:
Of course, this can be seen as yet another childish BD00 nitpick. But hey, what else is BD00 gonna do with his time? Solve world poverty? Occupy the org?
Quality is in all the freakin’ details, and when you see stuff like this in product code, it makes you wonder how many other risky, idiom-busting, code frags are lurking within the beast. But alas, where does one draw the line and let things like this slide?
As a final note, beware of disclosing turds like this to their authors; especially in mercenary cultures where everyone is implicitly “expected to” project an image of infallibility in order to “advance” their kuh-rearends. If you can excise turds like this yourself without getting caught, then please do so.
Useless Code
An Array Of Vectors Of Tuples
Yepp, that’s what I concocted recently to implement an algorithm. Pretty fugly, no?
If I told you what the algorithm is, I’d have to dispatch a missile carrying drone to seek out and kill you.
Admittance Of Imperfection
One of the traits I admire most about Bjarne Stroustrup is that he’s not afraid to look “imperfect” and point out C++’s weaknesses in certain application contexts. In his “Technical Report On C++ Performance“, Mr. Stroustrup helpfully cautions real time programmers to think about the risks of using the unpredictable/undeterministic features of the language:
Of course, C++ antagonists are quick to jump right on his back when Bjarne does admit to C++’s imperfections in specific contexts: “see, I told you C++ sux!“.
Here’s a challenge for programmers who read this inane blog. Can you please direct me to similar “warning” clauses written by other language designers? I’m sure there are many out there. I just haven’t stumbled across one yet.
Codan The Barbarian
In the Indigo release of Eclipse‘s C++ Development Tools (CDT) plugin, the Codan static code analyzer runs in real time as you type in your code. As shown below, you can customize the rule set that Codan enforces via the “Preferences/C++/Code Analysis” dialog window. (My fave is the “ambiguous problem” entry.)
The figure below shows a few examples of Codan in action. While typing in code, a gold (warning) or red (error) bug icon appears adjacent to the line number of the crappy code you write.
Some of Codan’s warnings and errors are also detected by good compilers, but it’s kind of neat that you can discover and correct your defects before running the compiler/linker. This feature is a boon for large programs that take a while to compile and link.
As a long time developer, I’m thrilled to death to have open source tools like Eclipse available to dolts like BD00. I remember the old days when there were not many commercial tools available, yet alone high caliber, open source tool suites like Eclipse.
Different Goals And Unfair Comparisons
At the behest of a work colleague, I revisited the Java programming language. I re-read James Gosling‘s 1995 white paper that introduced the language and I perused several Java-related wikipedia articles. Using those sources and Bjarne Stroustrup‘s “Evolving a language in and for the real world: C++ 1991-2006” paper, I developed the following side by side “design goals” lists:
In spite of these radically different design goals, people (including myself) continue to insist on comparing the languages in passionately irrational ways. If both language designs were driven by a common set of goals, then objectively valid comparisons could be made.
Java was intentionally designed from a blank sheet; unfettered from the ground up. Au contraire, C++ was intentionally designed by extending C and attempting to fix it’s short comings without breaking millions of lines of deployed code. It’s like comparing apples to oranges, dontcha think?
One Chart Summary
While flipping through Herb Sutter’s “C++ And Beyond” keynote speech charts, I stumbled upon this fabulous one chart summary of all (almost all?) the new features available in C++11.
Pretty intimidating, but cool, eh?
Doing Double Duty
In the industry I work in, domain analysts are called system engineers. The best system engineers, who mostly have electrical engineering backgrounds, know how to read code. Specifically, they know how to read C code because they learned it as a secondary subject in conjunction with hard core engineering courses (I actually learned FORTRAN in engineering school – because C hadn’t taken over the world yet).
Since the best engineers continuously move forward and grow, they often take on the challenge of moving from C to C++. One of the features that tends to trip them up is the dual use of the “&” token in C++ for “address of” and “reference to“. In C, there are no “references”, and hence, the “&” serves 1 purpose: it serves as the “address of” operator when applied to an identifier.
The code snippet and its associated output below show the classic, single purpose use of the “&” operator in C to obtain the “address of” an integer type identified by “x”.
In C++, the “&” token serves two purposes. The first one is the same as in C; when applied to an identifier, it returns the “address of” the object represented by the identifier. As the code below illustrates, the second C++ use is when it is applied to a type; it represents a “reference to” (a.k.a “alias to”) an object.
So, what good is a reference when C++ already has pointers? References are safer than pointers. When defining a pointer, C++ (like C) doesn’t require that it be initialized (as the first code fragment shows) to a valid address value immediately. Thus, if the code that initializes the pointer’s value to a valid address is far away from it’s definition, there’s a danger of mistakingly using it before the valid address has been assigned to it – as shown below. D’oh!
Since C++ requires a reference type to be initialized at its point of definition, there’s no chance of it ever being used in an invalid state. C++ compilers won’t allow it:
Another reason for “preferring” references over pointers in C++ is the notational convenience it provides for accessing class members:
It may be arguable, but besides saving one keystroke, using the “.” method of access instead of the “->” symbol provides for cleaner code, no?
So there you have it. If you’re a system engineer that is struggling to learn C++ for self-growth or code reviews, or a programmer trying to move from C onward toward C++ proficiency, hopefully this blog post helps. I know that expert C++ book authors can do a better job of the “what, how, and why” of references, but I wanted to take a shot at it myself. How did I do?
Note: I used Eclipse/cygwin/gcc over Win Vista for the code in this post. Do you see those annoying turd characters that surround the “r” in the pink compiler error output above? I’ve been trying to find out how to get rid of those pesky critters for weeks. As you can see, I’ve been unsuccessful. Can you help me out here?
Just As Fast, But Easier To Write
I love watching Herb Sutter videos on C++. His passion and enthusiasm for the language is infectious. Like Scott Meyers, Herb always explains the “why” and “how” of a language feature in addition to the academically dry “what” .
In this talk, “Writing modern C++ code: how C++ has evolved over the years“, Herb exhibits several side by side code snippets that clearly show much easier it is to write code in C++11 (relative to C++98) without sacrificing efficiency.
Here’s an example (which I hope isn’t too blurry) in which the C++11 code is shorter and obsoletes the need for writing an infamous”new/delete” pair.
Note how Herb uses the new auto, std::make_shared, std::shared_ptr, and anonymous lambda function features of C++11 to shorten the code and minimize the chance of making mistakes. In addition, Herb’s benchmarking tests showed that the C++11 code is actually faster than the C++98 equivalent. I don’t know about you, but I think this is pretty w00t!
I love paradoxes because they twist the logical mind into submission to the cosmos. Thus, I’m gonna leave you with this applicable quote (snipped from Herb’s presentation) by C++ expert and D language co-creator Andrei Alexandrescu:
Note: As a side bonus of watching the video, I found out that the Microsoft Parallel Patterns Library is now available for Linux (via Intel).
Biased Comparison
Let me preface this post by saying what lots of level-headed people (rightly) say: “choose the right tool for the right job“. Ok, having said that, take a quick glance again at the first word in this post’s title, and then let’s move on….
Take a look at the diagram below in terms of flexibility and performance. C++ provides developers with several programming style choices to solve the problem at hand and Java (Smalltalk, Eiffel) “handcuffs” programmers with no choice (in BD00’s twisted mind, Java Generics are clumsy and they destroy the OO purity of Java, and thus, don’t count).
Regarding program performance (<- ya gotta check this interactive site out), there’s “virtually” no way that a Java program running on top of an overhead “middleman” virtual machine can be faster than native code running on the same CPU hardware. Of course, there can be the rare exception where a crappy C++ compiler is pitted against a highly optimized (and over-hyped), “JIT” Java compiler .
Nevertheless, a price has to be paid for increased power and flexibility. And that price is complexity. The “learnability” of C++ is way more time consuming than Java. In addition, although it’s easy to create abominations in any language, it’s far easier to “blow your leg off” using C++ than using Java (or just about any other language except assembler).
Having spewed all this chit, I’d like to return to the quote in this post’s first paragraph: “choose the right tool for the right job“. Seriously consider using C++ for jobs like device drivers, embedded real-time systems, operating systems, virtual machines, and other code that needs to use hardware directly. Use Java, or even simpler languages, for web sites and enterprise IT systems.
The main weakness of OOP is that too many people try to force too many problems into a hierarchical mould. Not every program should be object-oriented. As alternatives, consider plain classes, generic programming, and free-standing functions (as in math, C, and Fortran). – Bjarne Stroustrup



















