Bulldozer00's Blog

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?

For the multi-threaded CSCI that I’m developing, I’ve got to receive and decode serialized messages off of “the wire” that conform to the design below. Depending on the value of “payloadType” in the message, each instance of the “WireMessage” class will have either an instance of “DataBlock1” or “DataBlock2” embedded within it.

After contemplating how to implement the deserialized replica of the message within my code, I decided to use a union to keep the message at a fixed size as it is manipulated and propagated forward through the non-polymorphic queues that connect the threads together in the CSCI.

The figure below shows side by side code snippets of the use of a union within a class. The code on the left compiled fine, but the compiler barfed on the code on the right with a “data member with constructor not allowed in union” error. WTF?

At first, I didn’t understand why the compiler didn’t like the code on the right. But after doing a little research, it made sense.

Unlike the code on the left, which has empty compiler-generated ctor, dtor, and copy operations, the DataBlock1 class on the right has a user-declared ctor – which trips up the compiler even though it is empty. When an object of FixedMessage type is created or destroyed, the compiler wouldn’t know which union member constructor or destructor to execute for the two class members in the union (built-in types like “int” don’t have ctors/dtors). D’oh!

Note: After I wrote this post, I found this better explanation on Bjarne Stroustrup’s C++0x FAQ page:

But of course, the restrictions on which user-defined types may be included in a union will be relaxed a bit in C++11. The details are in the link provided above.