C++ – Use of public typedefs in template class types

cclass-designtypedef

Recently I picked up the habit of typedefing various types within template classes, as is done in the standard library. For example, a container class might look something along the lines of:

template<typename T>
class custom_container {
public:
    typedef T value_type;
    typedef value_type* pointer;
    typedef value_type& reference;
    typedef std::size_t size_type;

    reference operator[](size_type);

    // etc...
};

However, after a while of using this, I began to question if it's really such a good idea, despite supposedly increasing readability and expression of intent.

It seems counter-intuitive that one would alias, say, T to another type, since isn't anyone using the class expecting the value_type to be T, and only ever T anyway (it is a custom_container<T> after all)? Similarly, would users of such a class not always expect pointer to be T* and reference to be T&?

We make use of typedefs to allow for ease of changing some aliased type to another if required, yet in the majority of the cases I come across, said typedefs are redundant, and almost confusing, as it would never make sense to have the alias synonymise any other type. custom_container probably wouldn't be fulfilling its expectations if value_type was changed to anything else than T – the user expects it is some sort of container of Ts.

Therefore, is it still useful and/or good design to make heavy use of typedefs in template classes as done in the standard library?

Best Answer

These typedefs are useful for two reasons:

for abbreviating the names of very complicated types such as iterator types.
for writing robust generic code that makes use of your templated type and isn't aware of T. Pre C++11 you cannot write some generic code without using these typedefs, or at least not without cumbersome helper templates.

Both of these reasons are less necessary since C++11: decltype() can be used to find many types like the value type, and auto can be used to avoid spelling out complicated type names.

But both of these have limits.

decltype() can sometimes produce unexpected types, especially around constness, references, or when implicit conversions are involved. E.g. given a std::vector<bool> xs, the value_type is bool but decltype(xs[0]) would be some reference wrapper object, unless xs is const in which case it is a bool again. Accounting for that correctly (possibly via std::decay?) is very difficult.
Since auto will happily resolve to any type, it is not suitable when you do want to document and enforce a specific type. In some places like function parameters you cannot use auto (though this is already allowed by some compilers as an implicit function template declaration).

Related Solutions

C++ Type Safety – Understanding Strongly Typed Typedef

These are phantom type parameters, that is, parameters of a parameterised type that are used not for their representation, but to separate different “spaces” of types with the same representation.

And speaking of spaces, that’s a useful application of phantom types:

template<typename Space>
struct Point { double x, y; };

struct WorldSpace;
struct ScreenSpace;

// Conversions between coordinate spaces are explicit.
Point<ScreenSpace> project(Point<WorldSpace> p, const Camera& c) { … }

As you’ve seen, though, there are some difficulties with unit types. One thing you can do is decompose units into a vector of integer exponents on the fundamental components:

template<typename T, int Meters, int Seconds>
struct Unit {
  Unit(const T& value) : value(value) {}
  T value;
};

template<typename T, int MA, int MB, int SA, int SB>
Unit<T, MA - MB, SA - SB>
operator/(const Unit<T, MA, SA>& a, const Unit<T, MB, SB>& b) {
  return a.value / b.value;
}

Unit<double, 0, 0> one(1);
Unit<double, 1, 0> one_meter(1);
Unit<double, 0, 1> one_second(1);

// Unit<double, 1, -1>
auto one_meter_per_second = one_meter / one_second;

Here we’re using phantom values to tag runtime values with compile-time information about the exponents on the units involved. This scales better than making separate structures for velocities, distances, and so on, and might be enough to cover your use case.

C++ Template Function – How to Pass Iterators

The range to iterate over

The C++ standard library offers something of a canonical form here, accumulate;

template< class InputIt, class T >
T accumulate( InputIt first, InputIt last, T init );

It takes a range from first to last (excluding last) and adds each element in the range to the init value as an initial value. It will also infer the return type from the initial type.

If the an implementation of sum is required, I would advise the use of accumulate here as is. If not suitable, the function signature taking the range [first, last) is "normal" as it mirror the standard library.

Deduce the return type

To get the value type "behind" the iterator, std::iterator_traits, in particular the embedded type value_type can be used;

typedef typename std::iterator_traits<InputIt>::value_type Result;
// .. default initialise
Result sum = Result{}; // or Result() if earlier than C++11

Design choice

I would design the function to (variation of option 2);

Accept a range [first, last)
Use std::iterator_traits (that work with pointers as well) to infer the return type
Use the C++11 default initialisation to initialise the result

As follows:

template <class Iterator, class U = typename std::iterator_traits<Iterator>::value_type>
U sum(Iterator first, Iterator last)
{
    U sum = U{};
    for (auto it = first; it != last; ++it) {
        sum += *it;
    }
    return sum;
}

An alternative with reduced template arguments.

template <class Iterator>
typename std::iterator_traits<Iterator>::value_type sum(Iterator first, Iterator last)
{
    using U = typename std::iterator_traits<Iterator>::value_type;
    U sum = U{};
    for (auto it = first; it != last; ++it) {
        sum += *it;
    }
    return sum;
}

Best Answer

Related Solutions

C++ Type Safety – Understanding Strongly Typed Typedef

C++ Template Function – How to Pass Iterators

Related Topic