模板化类型定义？答案

【问题标题】：templated typedef?模板化类型定义？
【发布时间】：2009-03-16 09:14:12
【问题描述】：

我正在使用 libgc，它是 C 和 C++ 的垃圾收集器。要使 STL 容器可进行垃圾回收，必须使用 gc_allocator。

而不是写

std::vector<MyType>

一个人必须写

std::vector<MyType,gc_allocator<MyType> >

有没有办法定义类似的东西

template<class T> typedef std::vector<T,gc_allocator<T> > gc_vector<T>;

我前段时间查了一下，发现这是不可能的。但我可能错了，或者可能有另一种方法。

以这种方式定义地图特别令人不快。

std::map<Key,Val>

变成

std::map<Key,Val, std::less<Key>, gc_allocator< std::pair<const Key, Val> > >

编辑：尝试使用宏后，我发现以下代码破坏了它：

#define gc_vector(T) std::vector<T, gc_allocator<T> >
typedef gc_vector( std::pair< int, float > ) MyVector;

模板化类型定义中的逗号被解释为宏参数分隔符。

所以看起来内部类/结构是最好的解决方案。

这是一个关于如何在 C++0X 中完成的示例

// standard vector using my allocator
template<class T>
using gc_vector = std::vector<T, gc_allocator<T> >;

// allocates elements using My_alloc
gc_vector <double> fib = { 1, 2, 3, 5, 8, 13 };

// verbose and fib are of the same type
vector<int, gc_vector <int>> verbose = fib;

【问题讨论】：

为什么说TypeHelper的方案需要你重新定义构造函数呢？它只不过是 typedef 上的一个快捷方式......
哎呀，你是对的。很好，您在回答中澄清了这一点。有人告诉我，C++0X 将通过使用 'using' 关键字提供更好的解决方案。你知道这是怎么回事吗？
C++0x 将提供模板别名，这将提供一种方法来完全按照您的意愿行事。 open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf
@WurmD 哪个更新了答案？我将接受的答案更改为提供 C++11 方法的答案。这是你问我的吗？

标签： c++ templates c++11 typedef

【解决方案1】：

您可以通过 using 使用 C++11 模板化类型别名，例如像这样

template <typename T>
using gc_vector = std::vector<T, gc_allocator<T>>;

_{注意：我知道这是一个老问题，但由于它有很多赞成票，而且当它出现在搜索结果中时，我认为它应该得到一个更新的答案。}

【讨论】：

【解决方案2】：

您不能使用“模板化 typedef”，但可以使用带有内部类型的便利类/结构：

template<typename T>
struct TypeHelper{
    typedef std::vector<T,gc_allocator<T> > Vector;
};

然后在你的代码中使用

TypeHelper<MyType>::Vector v;
TypeHelper<MyType>::Vector::iterator it;

地图也有类似的东西：

template<typename K,typename V>
struct MapHelper{
    typedef std::map<K, V, gc_allocator<K,V> > Map;
};

编辑 - @Vijay：我不知道是否还有其他可能的解决方法，这就是我的做法；宏可能会给你一个更紧凑的符号，但我个人不喜欢它：

#define GCVECTOR(T) std::vector<T,gc_allocator<T> >

编辑 - @chmike：请注意TypeHelper 解决方案不要求您重新定义构造函数！

【讨论】：

是的，有。在这种情况下，继承要简洁得多。
@sharptooth：确实，在这种情况下，继承为您提供了最好的表示法并避免使用宏，但正如 cmets 对您的回答所指出的那样，它的用法值得商榷。
我正在耐心等待任何潜在问题的证据。
我会用宏来选择答案，因为它是“最佳”解决方案。其他两种解决方案（继承或内部类/结构）都需要重新定义构造函数。该宏将在 typedef 指令中使用。
您可以在答案中添加模板类型定义（也称为模板别名）将包含在 C++0x 中（但是，gcc 尚不支持）open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2258.pdf。

【解决方案3】：

您可以公开继承：

template<class T>
class gc_vector<T> : public std::vector<T, gc_allocator<T> >
{
    public:
    // You'll have to redeclare all std::vector's constructors here so that
    // they just pass arguments to corresponding constructors of std::vector
};

这完全解决了您的问题。派生类型可以在可以使用基类型的任何地方使用，并且任何体面的编译器都没有实现开销。

如果您尝试通过指向基类变量的指针删除派生类变量，std::vector 具有非虚拟析构函数这一事实可能会导致根据 C++ 标准的未定义行为。

在现实世界中，在这种特殊情况下这无关紧要 - 派生类与基类相比没有添加任何新内容，因此派生类的析构函数只调用基类的析构函数。继续偏执，无论如何都要小心端口。

如果您从未在堆上分配此类变量（并且通常在堆栈上分配向量变量并作为其他类的成员），则非虚拟析构函数问题不会影响您。

【讨论】：

不，在这种情况下没关系。与基相比，派生没有新的数据成员，因此基 * 和派生 * 的删除之间没有区别。派生构造函数无论如何都只是调用基构造函数。
@sharptooth - 这很重要 - 你的建议可能会发生，但标准说它是 UB。
好吧，我希望标准不是逻辑和常识的替代品。您能否举例说明为什么这种情况可能会导致问题？
依赖未定义的行为是没有常识的。无论一种实现发生了什么，它本质上都是不可移植的。所以是的，在这种情况下，标准是“常识”的替代品。
很难举一个未定义行为的例子。如果愿意，符合要求的实现可以删除硬盘的内容。如果您在所有合理的系统上尝试它并且它按预期工作，请随时使用它知道它是未定义的。不过，作为一项规则，我会避开 UB。

【解决方案4】：

如果您愿意将编译器推向极限，可以使用宏来完成。我在为 Java 的“Future”和“Callable”类实现 C++ 等效项时做到了这一点。我们的库使用引用计数对象，因此“Reference”本身就是一个模板类，其中“T”派生自“ReferencedObject”。

1. Create your template Classes. Mine are:

    template<typename T>
    class Callable {
    private:

    public:
        virtual T Call() = 0;
    };

    template<typename T> CountedFuture : public ReferencedObject {
    private:
       Callable<T>* theTask;
       T            theResult;

    public:
       T Get() { 
          // Run task if necessary ...
          if(task) {
             theResult = theTask->Call();
             delete theTask;
          }
          return theResult;
       }
    };

2. In the application code I'm using references, so I define the macro:

   #define Future(T) Reference<CountedFuture<T>>

这样做的美妙之处在于，宏完全按照“模板 typedef”的要求执行操作，缺点是您不能使用“”作为类型参数，并且有没有类型推断。

3. I can now use the Macro wherever I would use a template, like in functions:

   Future(char*) DoSomething() { ... }
   bool          TestSomething(Future(std::string) f) { .... }

【讨论】：