Question

As discusses in The c++ Programming Language 3rd Edition in section 12.2.5, type fields tend to create code that is less versatile, error-prone, less intuitive, and less maintainable than the equivalent code that uses virtual functions and polymorphism.

As a short example, here is how a type field would be used:

void print(const Shape &s)
{
  switch(s.type)
  {
  case Shape::TRIANGE:
    cout << "Triangle" << endl;
  case Shape::SQUARE:
    cout << "Square" << endl;
  default:
    cout << "None" << endl;
  }
}

Clearly, this is a nightmare as adding a new type of shape to this and a dozen similar functions would be error-prone and taxing.

Despite these shortcomings and those described in TC++PL, are there any examples where such an implementation (using a type field) is a better solution than utilizing the language features of virtual functions? Or should this practice be black listed as pure evil?

Realistic examples would be preferred over contrived ones, but I’d still be interested in contrived examples. Also, have you ever seen this in production code (even though virtual functions would have been easier)?

Answer 1

When you “know” you have a very specific, small, constant set of types, it can be easier to hardcode them like this. Of course, constants aren’t and variables don’t, so at some point you might have to rewrite the whole thing anyway.

This is, more or less, the technique used for discriminated unions in several of Alexandrescu’s articles.

For example, if I was implementing a JSON library, I’d know each Value can only be an Object, Array, String, Integer, Boolean, or Null—the spec doesn’t allow any others.