Interesting Stuff

In today’s installment of “why not to program in C++,” I give you the following quiz, which Dustin, Steve, Tom, and I had to figure out today (Dustin’s code was doing the weirdest things, and we eventually traced it down to this):

Suppose you start out with the following code:

class Argument;
Argument x;
void Foo(const Argument& arg);
bool test;

You can assume that all of these are defined/initialized elsewhere in the code. For each pair of code snippets below, decide whether the two snippets are equivalent to each other.

if (test) Foo(x);
else Foo(Argument());

Foo(test ? x : Argument());
 

{ // limit the scope of y
  Argument y;
  Foo(test ? x : y);
}

Foo(test ? x : Argument());
 
 
 

Foo(x);

Foo(test ? x : x);

Foo(x);

Foo(true ? x : Argument());

Don’t read further until you think you have the answers.

Have you decided which are the same? Good.

Only the third pair are equivalent. Are you surprised? I certainly was! Here’s what’s going on:

Since Foo() takes an Argument reference, whatever is passed into Foo() must be an lvalue (something that can go on the left side of an equals operator). The lvalues here are x and y, but not Argument() (i.e., the line Argument() = x; would not be valid).

When the ternary operator (the ?: syntax) operates on two lvalues, the result is another lvalue. However, when it operates on something that is not an lvalue, the result isn’t one, either. To pass that result into Foo(), it needs to be placed in a temporary location (which is an lvalue and whose reference can be passed to Foo()). This means that the copy constructor is invoked, to copy the value returned by the ternary operator into a temporary location, so that Foo() can get a reference to that location.

So now, justifications for the answers:

1. If test is true, code snippet A does not call the copy constructor, while snippet B does (since the ternary operator won’t necessarily return an lvalue, it needs to copy it into a temporary location). If the copy constructor for Argument has side effects, the behavior of the snippets will differ. If the copy constructor does something unusual (for instance, it does not copy a certain member variable, or it resets the value of some internal state in the copy), Foo() will operate on different data in the two snippets (in B, it would operate on the new, uncopied member variable and the reset/reinitialized state, rather than x‘s version). Moreover, the location of the object passed into Foo() is different (one is x itself, while the other is a copy of x, stored somewhere else). It’s unlikely that Foo() will change its behavior based on the location of arg, but you never know. Note that if test is false, the copy constructor is not called in either snippet because even though the default constructor does not return an lvalue, it can be stored in an lvalue without using the copy constructor.
2. Again, when test is true, the copy constructor is invoked in snippet B but not in A. In snippet A, both operands in the ternary operator are lvalues, so it returns an lvalue, which can be used directly by Foo(), but this is not the case in snippet B, and the copy constructor needs to be invoked. This has the same issues as Problem 1. Moreover, if test is true, only snippet A invokes Argument‘s default constructor and destructor (which might have side effects of their own; in an extreme case, the constructor could change the value of test itself so that one snippet passes a newly constructed Argument to Foo while the other passes x or a copy thereof). Edit: also, if Argument is POD, y will be uninitialized in snippet A, so when test is false snippet A will operate on uninitialized data while snippet B will operate on data that has been zeroed out because it used the default constructor due to the parentheses. Just as before, the snippets have the same behavior if (edit: Argument is not POD and) test is false (both snippets call the default constructor, both call the destructor, and neither calls the copy constructor).
3. These really are the same. Since both parts of the ternary operator are lvalues, the result is an lvalue, and the copy constructor is not used.
4. Again, we have the same problems with the copy constructor being invoked in snippet B. Note that even in an optimized build, the copy constructor is still used! The test at the start of the ternary operator and the code to call the default constructor if the test turned out false are removed, but the copy constructor is still used in case you’re relying on one of the differences mentioned above.

This is yet another way in which C++ can have weird issues that are really hard to debug. If you are a fan of C++, please consider using a different (read: modern, high level) language. Both Java and Python only give you objects by reference, so the copy constructor would not be called in any of the above cases, which, for me at least, adheres more closely to the Principle of Least Surprise. The curmudgeons out there will want me to note that Java and Python do pass-by-value (not pass-by-reference, as you may have misinterpreted from my previous sentence) but the values themselves are references to the data stored in the objects, so they’re passing-by-value the references to the data. and yes, Python doesn’t really have a copy constructor, but that’s beside the point.

I realize that sometimes you need the speed available in C++, but there are a lot of times when it’s OK to be 2-3 times slower, and in those times you should use a language like Java (or Python, if you can stand being a bit slower than that). Remember that my Java runs just as fast on a new computer as your C++ does on a 2 year old computer. It’s not that big a performance hit.

Edit: See the addendum for another unexpected issue with the ternary operator.