Title: From Mechanism to Method

There are times when a generic (in the sense of general rather than template-based programming) type is needed, accommodating values of many other more specific types rather than C++'s normal strict and static types. We can distinguish three basic kinds of generic type:

In demonstrating substitutability concepts - conversions in particular - the remainder of this article is going to explore a generalized, discriminated union type named any.

Working from the inside out, how can a generic value contain any arbitrary value safely? A conventional union is out of the question as these alias only a predefined, fixed set of types. A next guess might land on a void * and const type_info * pairing. This seems to allow easy creation and querying, but falls down on type-safe copying and destruction: How can you correctly copy or delete an instance of a type of which you are unaware? From this question comes the seed of a solution: Inheritance and runtime polymorphism offer a form of substitutability between types that allows us to work safely through a common interface while ignoring the differences we can neither know nor manage. A virtual destructor provides the mechanism for safe deletion, and a virtual clone function offers a route for safe copying - effectively a Virtual Copy Constructor [Coplien1992, Gamma-1995]. However, this requires that value types inherit from a common base - not possible for pre-existing types - and would defeat the original objective of the any class.

Template classes provide a mechanism for defining arbitrary containers. Combining templates with derivation reveals a solution (see Listing 1). A generalized base class, placeholder, offers the required copying, querying, and deletable interface. From this, the templated holder class fills in the details for any arbitrary type. This example mixes derivation substitutability and generic substitutability. The generic interface requirement is that contained values must be CopyConstructible [ISO1998]. Clients of any remain blissfully unaware of all this encapsulated detail. This design is most generally an example of the Adapter pattern [Gamma-1995], and more specifically the External Polymorphism pattern [Cleeland-1998].

class any
{
public:
  any()
    : content(0)
  {
  }
  ~any()
  {
    delete content;
  }
  const std::type_info &type_info() const
  {
    return content ? 
          content->type_info() 
        : typeid(void);
  }
  ...
private:
  class placeholder
  {
  public:
    virtual ~placeholder()
    {
    }
    virtual const std::type_info &
               type_info() const = 0;
    virtual placeholder *
                  clone() const = 0;
  };
  template<typename value_type>
  class holder : public placeholder
  {
  public:
    holder(const value_type &value)
      : held(value)
    {
    }
    virtual const std::type_info &
                    type_info() const
    {
      return typeid(value_type);
    }
    virtual placeholder *clone() const
    {
      return new holder(held);
    }
    const value_type held;
  };
  placeholder *content;
};

An implicit conversion from one or more other types into one we are developing can be supported by the introduction of one or more single argument, converting constructors on a class. Such conversions should be used in support of making conceptually similar types substitutable, emphasizing their commonality, and allowing an existing type to be used where a new one is expected. For instance, string and char * are each different realizations of the concept of a character string. They are not perfect substitutes for one another, but there is an implied level of equivalence in meaning that should be respected and supported by the developer. Where single constructor arguments are needed, but equivalence does not make sense, the explicit keyword should be used. For instance, a file object may be initialised from a string representing its pathname, but it cannot be considered a realization of strings.

A degenerate form of conversion is the identity conversion, i.e. where an instance of a type can be converted into another instance of the same type. The copy constructor and assignment operator express this concept. An overloaded assignment operator can be used to optimise any use of a converting constructor followed by a copy assignment. For a string class, this means:

class string
{
public:
  string(const char *);
  string(const string &);
  string &operator=(const string &);
  string &operator=(const char *);
  ...
};

Providing converting constructor also provides the developer with a cast form for a type. It is not possible to define a literal form for a new type, but the constructor expression syntax comes close, e.g. string("theory"). This is stylistically preferable to using static_cast as the conversions are well-defined - as opposed to a potentially dangerous conversion that must be highlighted in the source code - and corresponds well to the idea of constructing a new value. The preferred "constructor literal" style also means that code appears consistent when used with other multiple argument constructed forms, e.g. string(5, '*').

Considering what inward conversions are reasonable to support can flesh the any class out further (see Listing 2). Certainly copying one any to another by construction or by assignment is essential for any value class. The copy constructor takes advantage of the representation's clone function to perform polymorphic copying, and a non-throwing swap function allows for an exception and self-assignment safe copy assignment operator [Henney1998, Sutter2000].

Employing the member template mechanism supports implicit conversion from values of an arbitrary type into an any. This is used in the converting constructor and the templated assignment operator, allowing values of any type to be used where an any is expected.

class any
{
public:
  ...
  any(const any &other)
    : content(other.content ?
          other.content->clone() : 0)
  {
  }
  template<typename value_type>
  any(const value_type &value)
    : content(new holder<value_type> 
                      (value))
  {
  }
  any &swap(any &rhs)
  {
    std::swap(content, rhs.content);
    return *this;
  }
  any &operator=(const any &rhs)
  {
    return swap(any(rhs));
  }
  template<typename value_type>
  any &operator=(const value_type &rhs)
  {
    return swap(any(rhs));
  }
  ...
};

Whereas a conversion from any type into an any type is widening, and therefore always safe, a conversion outward is narrowing, and therefore potentially unsafe - all types can be used where an any is expected but not vice-versa. Alas, the absence of explicit UDCs in the language means we cannot retain uniform usage syntax for casts whilst also preserving the constraint of explicitness. We must resort to a more conservative approach, such as the named to_ptr member template function (see Listing 3).

There is one query, however, that may be conveniently expressed through a UDC: Does an any hold a value? For many classes this immediately translates to operator bool. However, in many cases it turns out that bool is not the safest realization of a Boolean type. It introduces a number of subtle conversion problems for many classes, such as smart pointers [Meyers1996] or IOStreams, which at one stage in their standardization sported such an operator. These problems stem typically from bool's underlying integer nature: Its eagerness to participate in all kinds of (surprising) arithmetic and comparison. In contrast to bool, a const void * is positively hermit-like in its interactions with other types and operators.

Based on the to_ptr member template, it is possible to provide a checking cast, any_cast, that may be used to extract value's of a particular type from an any (see Listing 3).

class any
{
public:
  ...
  operator const void *() const
  {
    return content;
  }
  template<typename value_type>
  bool copy_to(value_type &value) const
  {
    const value_type *copyable =
                 to_ptr<value_type>();
    if(copyable)
      value = *copyable;
    return copyable;
  }
  template<typename value_type>
  const value_type *to_ptr() const
  {
    return type_info() == typeid(value_type)
    ? &static_cast<holder<value_type> *>
                     (content)->held
      : 0;
  }
  ...
};
template<typename value_type>value_type any_cast(const any &operand)
{
  const value_type *result 
        = operand.to_ptr<value_type>();
  return result ? *result 
              : throw std::bad_cast();
}