Template hi(template template parameter) template parameters allow us to
specify a em(class template) as a template parameter. By specifying a class
template, it is possible to add a certain kind of behavior (called a
emi(policy)) to an existing class template.

To specify an allocation em(policy), rather than an allocation tt(type)
for the class tt(Storage) we rephrase its class template header:
definition starts as follows:
        verb(    template <typename Data, template <typename> class Policy>
    class Storage...)

The second template parameter is new. It is a em(template template
parameter). It has the following elements:
    itemization(
    it() The keyword tt(template), starting the template template parameter;
    it() The keyword tt(template) is followed (between angle brackets) by a
        list of template parameters that must be specified for the template
        template parameter. These parameters em(may) be given names, but names
        are usually omitted as those names cannot be used in subsequent
        template definitions. On the other hand, providing formal names may
        help the reader of the template to understand the kind of templates
        that must be specified with the template template parameter.
    it() Template template parameters must match, in numbers and types (i.e.,
        template type parameters, template non-type parameters, template
        template parameters) the template parameters that must be specified
        for the policy. This can be tricky, as some templates use default
        parameters that are hardly ever changed (like the allocation schemes
        for containers). When specifying template template parameters those
        default types are used. If they should be specifiable then they must
        be added to the template template parameter's types. In the following
        example tt(fun) can only use the default allocator, tt(gun) em(must)
        specify the allocator when defining tt(vd), and tt(hun) defines a
        default allocator type, offering the option to either specify the
        allocator type or use the default type:
            verbinsert(-as4 examples/vector1.cc)
        Alternatively, em(alias templates), introduced in section
        ref(ALIASES), can be used to define names for templates using
        predefined parameter types.
    it() Following the bracketed list the keyword ti(class) or tt(typename) 
        em(must) be specified. 
    it() All parameters may be provided with default arguments. This is shown
        in the next example of a hypothetical class template:
        verb(template <
    template <
        typename = std::string,
        int = 12,
        template <typename = int> class Inner = std::vector
    >
    class Policy
>
class Demo
{
   ...
};)

Here, the class template tt(Demo) expects a template template parameter
        named tt(Policy), expecting three template parameters: a template type
        parameter (by default tt(std::string)); a template non-type parameter
        (by default having value 12); and tt(Policy) itself expects a template
        template parameter, called tt(Inner), by default using an tt(int) as
        its template type parameter.
       )
    Policy classes are often an integral part of the class under
consideration. Because of this they are often deployed as base classes. In the
example the class tt(Policy) could be used as a base class of the class
tt(Storage).

    The policy operates on the class tt(Storage)'s data type. Therefore the
policy is informed about that data type as well. Our class tt(Storage) now
begins like this:
        verb(    template <typename Data, template <typename> class Policy>
    class Storage: public Policy<Data>)

This automatically allows us to use tt(Policy)'s members when implementing
the members of the class tt(Storage).

    Our home-made allocation classes do not really provide us with many useful
members. Except for the extraction operator they offer no immediate access to
the data. This can easily be repaired by adding more members. E.g., the class
tt(NewAlloc) could be augmented with operators allowing access to and
modification of stored data:
            verb(        operator Data &()   // optionally add a `const' member too
        {
            return *d_data;
        }
        NewAlloc &operator=(Data const &data)
        {
            *d_data = data;
        })

The other allocation classes could be given comparable members.

    Let's use the allocation schemes in some real code. The next
example shows how tt(Storage) can be defined using some data type and an
allocation scheme. We start out again with a class tt(Storage):
        verb(    template <typename Data, template <typename> class Allocate>
    class Storage: public std::vector<Data, Allocate<Data>>
    {};)

That's all we have to do. Note that tt(std::vector) formally has two
template parameters. The first one is the vector's data type, which is always
specified; the second one is the allocator used by the vector. Usually the
allocator is left unspecified (in which case the default STL allocator is
used), but here it is mentioned explicitly, allowing us to pass our own
allocation policy to tt(Storage).

All required functionality is inherited from the tt(vector) base class, while
the policy is `factored into the equation' using a template template
parameter. Here's an example showing how this is done:
        verb(    Storage<std::string, NewAlloc> storage;

    copy(istream_iterator<std::string>(cin), istream_iterator<std::string>(),
            back_inserter(storage));

    cout << "Element index 1 is " << storage[1] << '\n';
    storage[1] = "hello";

    copy(storage.begin(), storage.end(),
         ostream_iterator<NewAlloc<std::string> >(cout, "\n"));)

Since tt(Storage) objects are also tt(std::vector) objects the STL tt(copy)
function can be used in combination with the em(back_inserter) iterator to add
some data to the tt(storage) object. Its elements can be accessed and modified
using the index operator. Then tt(NewAlloc<std::string>) objects are inserted
into tt(cout) (also using the tt(copy) function).

    Interestingly, this is not the end of the story. Remember that our
intention was to create a class allowing us to specify the em(storage type) as
well. What if we don't want to use a tt(vector), but instead would like to use
a tt(list)?

    It's easy to change tt(Storage)'s setup so that a completely different
storage type can be used on request, like a tt(deque). To implement this, the
storage class is parameterized as well, using yet another template template
parameter:
        verb(    template <typename Data, template <typename> class AllocationPolicy,
              template <typename, typename> class Container = std::vector>
    class Storage: public Container<Data, AllocationPolicy<Data>>
    {};)

The earlier example using a tt(Storage) object can be used again without
requiring any modifications at all (except for the above redefinition). It
clearly can't be used with a tt(list) container, as the tt(list) lacks
tt(operator[]). Trying to do so is immediately recognized by the compiler,
producing an error if an attempt is made to use tt(operator[]) on, e.g., a
    tt(list).footnote(A complete example showing the definition of the
allocation classes and the class tt(Storage) as well as its use is provided in
the annotations()'s distribution in the file
tt(yo/advancedtemplates/examples/storage.cc).) A tt(list) container, however
can still be specified as the container to use. In that case a tt(Storage) is
implemented as a tt(list), offering tt(list)'s interface, rather than
tt(vector)'s interface, to its users.
