Implementing Multiplication

Multiplication is a bit more complicated than addition and subtraction. So far, the dimensions of the arguments and results have all been identical, but when multiplying, the result will usually have different dimensions from either of the arguments. For multiplication, the relation:

(x^a)(x^b) == x ^{(a + b)}

implies that the exponents of the result dimensions should be the sum of corresponding exponents from the argument dimensions. Division is similar, except that the sum is replaced by a difference.

To combine corresponding elements from two sequences, we'll use MPL's transform algorithm. transform is a metafunction that iterates through two input sequences in parallel, passing an element from each sequence to an arbitrary binary metafunction, and placing the result in an output sequence.

template 
struct transform;  // returns a Sequence

The signature above should look familiar if you're acquainted with the STL transform algorithm that accepts two runtime sequences as inputs:

template <
    class InputIterator1, class InputIterator2
  , class OutputIterator, class BinaryOperation
>
void transform(
    InputIterator1 start1, InputIterator2 finish1
  , InputIterator2 start2
  , OutputIterator result, BinaryOperation func);

Now we just need to pass a BinaryOperation that adds or subtracts in order to multiply or divide dimensions with mpl::transform. If you look through the the MPL reference manual, you'll come across plus and minus metafunctions that do just what you'd expect:

#include 
#include 
#include 
namespace mpl = boost::mpl;

BOOST_STATIC_ASSERT(( 
    mpl::plus<
        mpl::int_<2>
      , mpl::int_<3>
    >::type::value == 5
));

At this point it might seem as though we have a solution, but we're not quite there yet. A naive attempt to apply the transform algorithm in the implementation of operator* yields a compiler error:

#include 

template 
quantity< 
    T
  , typename mpl::transform::type
>
operator*(quantity x, quantity y) { ... }

It fails because the protocol says that metafunction arguments must be types, and plus is not a type, but a class template. Somehow we need to make metafunctions like plus fit the metadata mold.

One natural way to introduce polymorphism between metafunctions and metadata is to employ the wrapper idiom that gave us polymorphism between types and integral constants. Instead of a nested integral constant, we can use a class template nested within a metafunction class:

struct plus_f
{
    template 
    struct apply
    {
       typedef typename mpl::plus::type type;
    };
};

Whereas a metafunction is a template but not a type, a metafunction class wraps that template within an ordinary non-templated class, which is a type. Since metafunctions operate on and return types, a metafunction class can be passed as an argument to, or returned from, another metafunction.

Finally, we have a BinaryOperation type that we can pass to transform without causing a compilation error:

template 
quantity< 
    T
  , typename mpl::transformplus_f>::type  // new dimensions
>
operator*(quantity x, quantity y)
{
    typedef typename mpl::transformplus_f>::type dim;
    return quantity( x.value() * y.value() );
}

Now, if we want to compute the force exterted by gravity on a 5 kilogram laptop computer, that's just the acceleration due to gravity (9.8 m/sec²) times the mass of the laptop:

quantity m(5.0f);
quantity a(9.8f);
std::cout << "force = " << (m * a).value();

Our operator* multiplies the runtime values (resulting in 6.0f), and our metaprogram code uses transform to sum the meta-sequences of fundamental dimension exponents, so that the result type contains a representation of a new list of exponents, something like:

mpl::vector_c

However, if we try to write:

quantity f = m * a;

we'll run into a little problem. Although the result of m * a does indeed represent a force with exponents of mass, length, and time 1, 1, and -2 respectively, the type returned by transform isn't a specialization of vector_c. Instead, transform works generically on the elements of its inputs and builds a new sequence with the appropriate elements: a type with many of the same sequence properties as mpl::vector_c, but with a different C++ type altogether. If you want to see the type's full name, you can try to compile the example yourself and look at the error message, but the exact details aren't important. The point is that force names a different type, so the assignment above will fail.

In order to resolve the problem, we can add an implicit conversion from the multiplication's result type to quantity. Since we can't predict the exact types of the dimensions involved in any computation, this conversion will have to be templated, something like:

template 
struct quantity
{
    // converting constructor
    template 
    quantity(quantity const& rhs)
      : m_value(rhs.value())
    {
    }
    ...

Unfortunately, such a general conversion undermines our whole purpose, allowing nonsense such as:

// Should yield a force, not a mass!
quantity bogus = m * a;

We can correct that problem using another MPL algorithm, equal, which tests that two sequences have the same elements:

template 
quantity(quantity const& rhs)
  : m_value(rhs.value())
{
    BOOST_STATIC_ASSERT((
       mpl::equal::type::value
    ));
}

Now, if the dimensions of the two quantities fail to match, the assertion will cause a compilation error.