Каковы некоторые виды использования параметров шаблона шаблона?

на самом деле, usecase для параметров шаблона шаблона довольно очевидно. Как только вы узнаете, что c++ stdlib имеет зияющую дыру, не определяющую операторы вывода потока для стандартных типов контейнеров, вы продолжите писать что-то вроде:

template<typename T>
static inline std::ostream& operator<<(std::ostream& out, std::list<T> const& v)
{
    out << '[';
    if (!v.empty()) {
        for (typename std::list<T>::const_iterator i = v.begin(); ;) {
            out << *i;
            if (++i == v.end())
                break;
            out << ", ";
        }
    }
    out << ']';
    return out;
}

тогда вы поймете, что код для вектора один и тот же, для forward_list один и тот же, на самом деле, даже для множества типов карт он все тот же. Эти классы шаблонов не имеют ничего общего, кроме мета-интерфейс / протокол, а использование параметра шаблона шаблона шаблона позволяет фиксировать общность во всех из них. Прежде чем приступить к написанию шаблона, стоит проверить ссылку, чтобы вспомнить, что контейнеры последовательности принимают 2 аргумента шаблона - для типа значения и распределителя. Хотя распределитель по умолчанию, мы все равно должны учитывать его существование в нашем операторе шаблона

template<template <typename, typename> class Container, class V, class A>
std::ostream& operator<<(std::ostream& out, Container<V, A> const& v)
...

вуаля, которая будет работать автоматически для всех существующих и будущих контейнеров последовательности соблюдение стандартного протокола. Чтобы добавить карты в микс, нужно взглянуть на ссылку, чтобы отметить, что они принимают 4 шаблона params, поэтому нам понадобится другая версия оператора

Btw, с C+11 который позволяет variadic шаблонам (и таким образом должен позволять variadic template template args), можно было бы иметь один оператор

#include <iostream>
#include <vector>
#include <deque>
#include <list>

template<typename T, template<class,class...> class C, class... Args>
std::ostream& operator <<(std::ostream& os, const C<T,Args...>& objs)
{
    os << __PRETTY_FUNCTION__ << '\n';
    for (auto const& obj : objs)
        os << obj << ' ';
    return os;
}

int main()
{
    std::vector<float> vf { 1.1, 2.2, 3.3, 4.4 };
    std::cout << vf << '\n';

    std::list<char> lc { 'a', 'b', 'c', 'd' };
    std::cout << lc << '\n';

    std::deque<int> di { 1, 2, 3, 4 };
    std::cout << di << '\n';

    return 0;
}

выход

std::ostream &operator<<(std::ostream &, const C<T, Args...> &) [T = float, C = vector, Args = <std::__1::allocator<float>>]
1.1 2.2 3.3 4.4 
std::ostream &operator<<(std::ostream &, const C<T, Args...> &) [T = char, C = list, Args = <std::__1::allocator<char>>]
a b c d 
std::ostream &operator<<(std::ostream &, const C<T, Args...> &) [T = int, C = deque, Args = <std::__1::allocator<int>>]
1 2 3 4 

вот простой пример, взятый из 'современный дизайн C++ - общие шаблоны программирования и дизайна" Андрей Александреску:

Он использует классы с параметрами шаблона шаблона для реализации шаблона политики:

// Library code
template <template <class> class CreationPolicy>
class WidgetManager : public CreationPolicy<Widget>
{
   ...
};

Он объясняет: как правило, класс host уже знает или может легко вывести аргумент шаблона класса политики. В приведенном выше примере WidgetManager всегда управляет объектами типа Widget, поэтому требование пользователя снова указать виджет в экземпляре CreationPolicy является избыточным и потенциально опасным.В этом случае код библиотеки может использовать параметры шаблона шаблона для указания политик.

эффект заключается в том, что клиентский код может использовать "WidgetManager" более элегантно:

typedef WidgetManager<MyCreationPolicy> MyWidgetMgr;

вместо более громоздкого и подверженного ошибкам способа определения, в котором отсутствовали бы аргументы шаблона шаблона, потребовалось бы:

typedef WidgetManager< MyCreationPolicy<Widget> > MyWidgetMgr;

вот еще один практический пример из моей библиотека сверточных нейронных сетей CUDA. У меня есть следующий шаблон класса:

template <class T> class Tensor

который фактически реализует манипуляцию n-мерными матрицами. Существует также шаблон дочернего класса:

template <class T> class TensorGPU : public Tensor<T>

который реализует ту же функциональность, но в GPU. Оба шаблона могут работать со всеми основными типами, такими как float, double, int и т. д И у меня также есть шаблон класса (упрощенно):

template <template <class> class TT, class T> class CLayerT: public Layer<TT<T> >
{
    TT<T> weights;
    TT<T> inputs;
    TT<int> connection_matrix;
}

причина здесь иметь синтаксис шаблона шаблона заключается в том, что я могу объявить реализацию класса

class CLayerCuda: public CLayerT<TensorGPU, float>

который будет иметь как веса, так и входы типа float и на GPU, но connection_matrix всегда будет int, либо на CPU (указав TT = Tensor), либо на GPU (указав TT=TensorGPU).

скажем, вы используете CRTP для предоставления "интерфейса" для набора дочерних шаблонов; и как родитель, так и ребенок являются параметрическими в других аргументах шаблона:

template <typename DERIVED, typename VALUE> class interface {
    void do_something(VALUE v) {
        static_cast<DERIVED*>(this)->do_something(v);
    }
};

template <typename VALUE> class derived : public interface<derived, VALUE> {
    void do_something(VALUE v) { ... }
};

typedef interface<derived<int>, int> derived_t;

обратите внимание на дублирование "int", которое на самом деле является одним и тем же параметром типа, указанным для обоих шаблонов. Вы можете использовать шаблон шаблона для производных, чтобы избежать этого дублирования:

template <template <typename> class DERIVED, typename VALUE> class interface {
    void do_something(VALUE v) {
        static_cast<DERIVED<VALUE>*>(this)->do_something(v);
    }
};

template <typename VALUE> class derived : public interface<derived, VALUE> {
    void do_something(VALUE v) { ... }
};

typedef interface<derived, int> derived_t;

обратите внимание, что вы исключаете прямое предоставление других параметров шаблона производные шаблон; "интерфейс" по-прежнему получает их.

Это также позволяет создавать typedefs в "интерфейсе", которые зависят от параметров типа, которые будут доступны из производного шаблона.

вышеупомянутый typedef не работает, потому что вы не можете typedef к неуказанному шаблону. Однако это работает (и C++11 имеет встроенную поддержку template typedefs):

template <typename VALUE>
struct derived_interface_type {
    typedef typename interface<derived, VALUE> type;
};

typedef typename derived_interface_type<int>::type derived_t;

вам нужен один derived_interface_type для каждого экземпляра производный шаблон к сожалению, если нет другого трюка, который я еще не узнал.

в решении с вариадическими шаблонами, предоставленными pfalcon, мне было трудно фактически специализировать оператор ostream для std:: map из-за жадного характера вариадной специализации. Вот небольшая ревизия, которая сработала для меня:

#include <iostream>
#include <vector>
#include <deque>
#include <list>
#include <map>

namespace containerdisplay
{
  template<typename T, template<class,class...> class C, class... Args>
  std::ostream& operator <<(std::ostream& os, const C<T,Args...>& objs)
  {
    std::cout << __PRETTY_FUNCTION__ << '\n';
    for (auto const& obj : objs)
      os << obj << ' ';
    return os;
  }  
}

template< typename K, typename V>
std::ostream& operator << ( std::ostream& os, 
                const std::map< K, V > & objs )
{  

  std::cout << __PRETTY_FUNCTION__ << '\n';
  for( auto& obj : objs )
  {    
    os << obj.first << ": " << obj.second << std::endl;
  }

  return os;
}


int main()
{

  {
    using namespace containerdisplay;
    std::vector<float> vf { 1.1, 2.2, 3.3, 4.4 };
    std::cout << vf << '\n';

    std::list<char> lc { 'a', 'b', 'c', 'd' };
    std::cout << lc << '\n';

    std::deque<int> di { 1, 2, 3, 4 };
    std::cout << di << '\n';
  }

  std::map< std::string, std::string > m1 
  {
      { "foo", "bar" },
      { "baz", "boo" }
  };

  std::cout << m1 << std::endl;

    return 0;
}

вот с чем я столкнулся:

template<class A>
class B
{
  A& a;
};

template<class B>
class A
{
  B b;
};

class AInstance : A<B<A<B<A<B<A<B<... (oh oh)>>>>>>>>
{

};

можно решить, чтобы:

template<class A>
class B
{
  A& a;
};

template< template<class> class B>
class A
{
  B<A> b;
};

class AInstance : A<B> //happy
{

};

или (работает код):

template<class A>
class B
{
public:
    A* a;
    int GetInt() { return a->dummy; }
};

template< template<class> class B>
class A
{
public:
    A() : dummy(3) { b.a = this; }
    B<A> b;
    int dummy;
};

class AInstance : public A<B> //happy
{
public:
    void Print() { std::cout << b.GetInt(); }
};

int main()
{
    std::cout << "hello";
    AInstance test;
    test.Print();
}

вот один обобщенный из того, что я только что использовал. Я отправляю его, так как это очень простой пример, и он демонстрирует практический случай применения наряду с аргументами по умолчанию:

#include <vector>

template <class T> class Alloc final { /*...*/ };

template <template <class T> class allocator=Alloc> class MyClass final {
  public:
    std::vector<short,allocator<short>> field0;
    std::vector<float,allocator<float>> field1;
};

Он улучшает читаемость вашего кода, обеспечивает дополнительную безопасность типов и экономит некоторые усилия компилятора.

скажем, вы хотите распечатать каждый элемент контейнера, вы можете использовать следующий код без параметра шаблона шаблона

template <typename T> void print_container(const T& c)
{
    for (const auto& v : c)
    {
        std::cout << v << ' ';
    }
    std::cout << '\n';
}

или с параметром шаблона шаблон

template< template<typename, typename> class ContainerType, typename ValueType, typename AllocType>
void print_container(const ContainerType<ValueType, AllocType>& c)
{
    for (const auto& v : c)
    {
        std::cout << v << ' ';
    }
    std::cout << '\n';
}

Предположим, вы передаете целое число, скажем print_container(3). В первом случае шаблон будет создан компилятором, который будет жаловаться на использование c in цикл for, последний не будет создавать экземпляр шаблона вообще, поскольку соответствующий тип не может быть найден.

вообще говоря, если ваш класс/функция шаблона предназначен для обработки класса шаблона в качестве параметра шаблона, лучше сделать это ясно.