The need often arises in C++ to work around weaknesses inherited from C. One particularly onerous issue is the implicit, narrowing conversion of primitive types. Narrowing conversions are easily made by accident, without any warning from the compiler. For example, the following is entirely legal C++:

    int const pi = 3.14159;

The author obviously meant to use some type other than int. Usually, problems resulting from implicit conversions are more subtle. Consider the case of function argument conversion:

    int square(int i) {
        return i * i;
    }

    double const radius = 2.6;
    double const area = 3.14159 * square(radius); // Whoops.

Unless square has been appropriately overloaded, radius will be implicitly converted from 2.6 to 2. The integer result will be widened to double, and area will be initialized to 12.56636, rather than 21.2371484. This kind of bug does not always jump out at a tired programmer staring blearily at a debugger. The worst part is that the conversion has already been performed before square even begins executing, so there is no way for the author of square to detect, much less prevent, such accidents. Or is there?

A Solution

Suppose we have written square(int) as part of a library of fixed-point math functions. We want to accept ints, but do not want those ints to be constructed implicitly from any other type. What we need is a hook into the overload resolution process itself, to prevent square(int) being selected in the first place.

One approach is to declare, but not define, a catch-all function template:

    template<typename T> T square(T);

Whenever square is passed an argument of any type other than int, the template will be resolved in preference to square(int). Since the template is never defined, a link error will ensue, saving our clients from the dreaded implicit conversion. Voilá!

This approach has two major drawbacks:

1. A separate template is needed for every function in the library.

           int square(int i) {
               return i * i;
           }

           int cube(int i) {
               return i * square(i);
           }

           …

           template<typename T> T square(T);
           template<typename T> T cube(T);

           …

2. Although reported errors at link-time are a major improvement over silent errors at run-time, the issue really has nothing to do with linking. We ought to be able to catch it at compile-time.

The first problem will make maintenance difficult for us, the library developers, while the second will make life difficult for our clients. Let’s tackle the problems in order.

DRYness Through AOP

The error-catching template declarations have a great deal of commonality. Such near-duplicate fragments are sometimes called “code clones,” and are widely recognized as maintenance nightmares. In Agile development, the principle that one should avoid code clones is called DRY: Don’t Repeat Yourself.

In the case at hand, we can DRY our code by taking an aspect-oriented approach. We really want to tackle a cross-cutting concern of our library, namely function argument passing, rather than a bunch of manually selected functions. As with most problems in software development, what we need is a new abstraction; and, as is often the case in C++, the abstraction is best implemented by a new static type:

    struct only_int
    {
        int value;

        /* Declared, but never defined. */
        template<typename T> only_int( T );

        only_int( int i )
            : value( i ) { }
    };

Instances of this class are constructible from int, but not from any other primitive or client-defined type. Our library functions can use it directly, with no need for per-function template declarations:

    int square(only_int i) {
        return i.value * i.value;
    }

    int cube(only_int i) {
        return i.value * square(i);
    }

    …

So much for the code clones.

Better Diagnostics Through Early Binding

Next, we would like to move the error reporting from link time to compile time. Fortunately, C++ includes a powerful mechanism for controlling access to class members. To deny client access to the catch-all constructor template, we define our class using the class keyword (rather than struct), thereby making the default access level private. We explicitly mark the rest of the class public.

    class only_int
    {
        template<typename T> only_int( T );

      public:

        int value;

        only_int( int i )
            : value( i ) { }
    };

Our library now generates the compile-time error we originally sought. Modern compilers will print, as part of the diagnostic message, the exact location of the error in client code.

    $ cat client.cc
    using integer_math::square;

    double const radius = 2.6;
    double const area = 3.14159 * square(radius);

    $ g++ -include integer_math.hh -c client.cc
    ./integer_math.hh:6: error: ‘template<class T> integer_math::only_int::only_int(T)’ is private
    client.cc:4: error: within this context

Generalizing

The benefits of class-based abstraction have already come into play: The addition of access control to our class automatically applies to all of our integer math functions, without requiring any syntactic changes in them. There are still, however, plenty of potential modifications to only_int that could require corresponding changes in our library function definitions. Such scattered changes constitute a royal pain in the neck. It will be wise to generalize our class as much as possible now, rather than leave ourselves open to downstream headaches.

One obvious generalization is to support wrapping of any given type, rather than hard-coding int. Implicit conversions are not unique to int; if our math library one day needs to accept other types, we would like to enable them selectively. The solution here is to generate our only_int type from a generic class template:

    template<typename T>
    class only
    {
        template<typename U> only( U );

      public:

        T value;

        only( T t )
            : value( t ) { }
    };

    typedef only<int> only_int;

Whenever we define such generic templates, it is a good idea to provide publicly accessible type names that support compile-time introspection, and to use only these names in public member declarations:

    template<typename T>
    class only
    {
        template<typename U> only( U );

      public:

        typedef T value_type;

        value_type value;

        only( value_type v )
            : value( v ) { }
    };

The next potential pitfall comes from the public member variable only<T>::value. Technically, the problem is not that only<T>::value is a public variable, but that the syntax for accessing variables in C++ is different from the syntax for calling functions, overloaded conversion operators notwithstanding. If we ever want some code to be run automatically when a value is accessed, we require that all accesses use function-call syntax. We might as well bite that bullet now, by making only<T>::value private, and providing an accessor function. This does require us to touch all of our library function definitions, one last time.

    template<typename T>
    class only
    {
        T m_value;

        template<typename U> only( U );

      public:

        typedef T value_type;

        only( value_type v )
            : m_value( v ) { }

        value_type get() const {
            return m_value;
        }
    };

    int square(only_int i) {
        return i.get() * i.get();
    }

    int cube(only_int i) {
        return i.get() * square(i);
    }

    …

Further generalization is yet to be had, but it will have to wait for a future article. Stay tuned for optional pass-by-reference, the Open/Closed Principle, and policy-based design.