Gotcha #36: Misusing Conversion Operators

Overuse of conversion operators increases code complexity. Because the compiler applies them implicitly, the presence of too many conversion operators in a class can result in ambiguity:

class Cell { 


 public:


   // . . .


   operator int() const;


   operator double() const;


   operator const char *() const;


   typedef char **PPC;


   operator PPC() const;


   // etc . . .


};

A Cell can answer so many different requirements that its users may frequently find it answers more than one simultaneously, with the result of compile-time ambiguity. Worse, in cases with no ambiguity and no compile-time error, it's still often difficult to determine precisely what implicit conversion the compiler has employed. It's generally better to dispense with conversion operators where many conversions are required and employ the more straightforward alternative of explicit conversion functions:

class Cell { 


 public:


   // . . .


   int toInt() const;


   double toDouble() const;


   const char *toPtrConstChar() const;


   char **toPtrPtrChar() const;


   // etc . . .


};

Ordinarily, one would expect to have no more than a single conversion operator in a class, if that. The presence of two is worth a second look. The presence of three or more is an indication that it's time to get a second opinion.

Even a single conversion operator may provoke ambiguity in combination with a constructor:

class B; 





class A {


 public:


   A( const B & );


   // . . .


};





class B {


 public:


   operator A() const;


   // . . .


};

There are two ways to convert a B to an A implicitly: A's constructor or B's conversion operator. The result is an ambiguity:

extern A a; 


extern B b;


a = b; // error! ambiguous


a = b.operator A(); // OK, but odd


a = A(b); // error! ambiguous

Note the lack of a direct way to invoke a constructor or take its address. The expression A(b) is, therefore, not a constructor call, even though such expressions often result in the invocation of a constructor. It's a request to convert b to type A by any means whatsoever, and it's still ambiguous. (Unfortunately, most compilers will nevertheless not flag the error and will use class A's constructor to perform the conversion.)

It's typically better to dispense with conversion operators, declare single-argument constructors explicit, and avoid implicit conversions, except in cases where their presence is really appropriate. Where nonexplicit constructors and conversion operators are indicated, a rule of thumb is to prefer the use of constructors to convert from user-defined types and conversion operators to convert only to pre defined types.

The purpose of conversion operators is to further integrate an abstract data type into an existing type system, by providing implicit conversions that mirror the implicit conversions supported by the predefined types. It's a mistake to use a conversion operator to implement a "value-added" conversion:

class Complex { 


   //  . . .


   operator double() const;


};


Complex velocity = x + y;


double speed = velocity;





class Container {


   // . . .


   virtual operator Iterator *() const = 0;


};


Container &c = getNewContainer();


Iterator *i = c;

Here, the designer of the Complex class wants to be able to determine the length of the vector defined by the complex number. However, a user of this interface may assume that the conversion to double returns the real part of the complex, the imaginary part, the angle of the vector, or any other reasonable interpretation. The intent of the conversion is unclear.

The designer of the abstract Container interface would like to implement a Factory Method that returns a pointer to an appropriate iterator into the concrete container derived from Container. However, we're not converting a Container into an Iterator, and implementation of the Factory Method as a conversion is confusing and inappropriate. It could also cause maintenance problems if the Factory Method should require an argument in the future. Because the conversion operator cannot take an argument, it would have to be replaced by a non-operator function. This, in turn, would force all users of the Container class to locate and rewrite all the implicit uses of the conversion operator.

It's much better to reserve conversion operators for their intended use as conversions. Better interfaces for all these design goals are better achieved with non-operator functions:

class Complex { 


   // . . .


   double magnitude() const;


};


Complex velocity = x + y;


double speed = velocity.magnitude();





class Container {


   // . . .


   virtual Iterator *genIterator() const = 0;


};


Container &c = getNewContainer();


Iterator *i = c.genIterator();

This advice holds, I claim, even in the case of a simple conversion to bool (or, sometimes, void *) to indicate that an object is in a valid or usable state:

class X { 


 public:


   virtual operator bool() const = 0;


   // . . .


};


// . . .


extern X &a;


if( a ) {


   // a is usable . . .

Once again, this "value-added" use of the conversion operator results in imprecision. In the future, we may wish to distinguish among X objects that are invalid, unusable, or corrupted. It's better to be precise:

class X { 


 public:


   virtual bool isValid() const = 0;


   virtual bool isUsable() const = 0;


   // . . .


};


// . . .


if( a.isValid() ) {


   // . . .

The standard iostream library employs conversion operators to allow an easy check on the state of an iostream:

if( cout ) // is cout in a good state? 


   // . . .

An operator void * provides this capability, and the statement above would be translated in a way similar to this:

if( static_cast<bool>(cout.operator void *()) ) // . . . 

If the iostream is in a bad state, the conversion operator returns a null pointer; otherwise, it returns a non-null pointer. Since the conversion from a pointer to a bool is predefined, it may be used to test the state of the iostream. Unfortunately, it may also be used to set the value of a void pointer:

void *coutp = cout; // odd and almost useless 


cout << cout << cin << cerr; // print some void *'s

However, the existence of a conversion from an iostream to a void *, while odd, is not as problematic as the existence of a conversion to bool would be:

cout >> 12; // won't compile, fortunately 

Here, we've made the common mistake of using the right-shift operator rather than the left-shift operator with an output stream. If it were possible to convert an output stream directly to a bool, this statement would compile. cout would be converted to a bool value, which, in turn, would be converted to int, and the result would be shifted 12 bit positions to the right. Clearly, the conversion of cout to void * is preferable to a conversion to bool, but it would have been an even better design to dispense with conversion operators entirely, in preference to a clear and unambiguous member function:

if( !cout.fail() ) 


   // . . .