【问题标题】:Nested template explicit specialization嵌套模板显式特化
【发布时间】:2018-10-19 19:52:03
【问题描述】:

我有一些编译器行为 - 在 VisualC++ 和 g++ 上有所不同 - 我不理解(对于任一编译器)。我会用英文描述它,但也许只看下面的代码会更容易。

它与具有成员类模板和成员函数模板的类模板有关。我正在尝试同时

  1. 显式特化外部类模板(不特化成员模板)
  2. 在外部类模板的显式特化显式特化成员模板。

我发现,对于这两个编译器,如果我执行 任一 #1(显式特化外部类模板)或 #2(显式特化成员模板),一切都可以正常编译(并且实例化符合预期) .

但如果我尝试同时执行 #1 和 #2(我相信以正确的顺序声明),我会发现

  • 使用 g++,我可以为成员类模板执行此操作,但在成员模板类声明中出现编译器错误。
  • 对于 VC++,我得到两个成员模板的编译器错误。

这是外部类模板的主要定义。在以下所有情况下都是一样的:

// Class template with a member class template and a member function template
template <int I>
struct OuterClass
{
    template <int J> struct InnerClass {};
    template <int J> static void InnerFunc() {}
};

这里只做#1(明确专门化外部类模板)。这编译得很好并且实例化符合预期。

// Explicit specialization of outer class template,
// leaving member templates unspecialized.
template <>
struct OuterClass<1>
{
    template <int J> struct InnerClass {};
    template <int J> static void InnerFunc() {}
};

这里只做#2(明确专门化成员模板)。这编译得很好并且实例化符合预期。

// Explicit specialization of inner templates for
// an explicit specialization of outer class template
template <> template <> struct OuterClass<1>::InnerClass<1> {};
template <> template <> void OuterClass<1>::InnerFunc<1>() {}

这里尝试同时执行 #1 和 #2 - 只需将之前的两个代码 sn-ps 粘贴在一起即可:

// Explicit specialization of outer class template,
// leaving member templates unspecialized.
template <>
struct OuterClass<1>
{
    template <int J> struct InnerClass {};
    template <int J> static void InnerFunc() {}
};

// Explicit specialization of inner templates for
// an explicit specialization of outer class template
template <> template <> struct OuterClass<1>::InnerClass<1> {};  // Line A
template <> template <> void OuterClass<1>::InnerFunc<1>() {}    // Line B

g++ 可以很好地编译“A 行”(并且实例化符合预期)。但是 g++ 给出了 B 行的编译器错误:“模板参数列表太多”。

VC++ 为“A 行”和“B 行”都给出了编译器错误(这里太杂乱了,不胜枚举)。

同样,对于两个编译器,“A 行”和“B 行”都可以正常编译,因为它们在外部类模板的显式特化之后没有出现。

据我了解,一切都应该编译得很好。那么谁是对的——我、g++ 还是 VC++?更重要的是,为什么?

请理解这不是一个“我如何完成 X”的问题,这是一个“我想完全理解 C++”的问题。如果您花时间阅读并考虑一下,我会感谢您...我希望我尽可能地简化它。

【问题讨论】:

  • 如果我确定的话,我会回答这个问题。但我以前从未见过双重template&lt;&gt; template&lt;&gt;。使用单个 template&lt;&gt; 它可以很好地与 Microsoft ms140 一起编译。
  • @lakeweb 在 gcc 和 clang 中也是如此。然而,在 C++ 草案中的“模板->模板实例化和专业化->显式专业化”部分的 pt 14-15 中有“模板模板”的示例(其数量因版本而异)
  • 嗨@max360 谢谢。所以我通读了this,它更有意义。我找不到规则,但似乎知道您不能复制专业化。因此,使用双 template&lt;&gt; 是对新专业化的请求,struct OuterClass&lt;1&gt; 已经完成。我接近了吗?
  • @lakeweb 感谢您的回复,您是对的,单个模板 使用 MSVC 编译,同时存在 #1 和 #2。这让我朝着正确的方向开始,我想我明白了 - 请在下面查看我的自我回答。正如 max630 指出的那样,有时“模板”的多次出现是合法的(并且是必需的) - 另请参见我的答案中的代码示例和 en.cppreference.com/w/cpp/ 底部的示例语言/模板专业化。

标签: c++


【解决方案1】:

我在这个问题上花了很多时间,我想我已经弄明白了——“弄明白”的意思是我确切地知道在我尝试过的两个编译器(MSVC 和g++),以及每个编译器使用什么语法。这一切都很丑陋,但它是可预测和可重复的 - 我有很多示例代码未在此处显示,我从中推断出结果。为了清楚起见并避免我感到沮丧,这里的描述不是我的理论,而是在数百个示例案例中观察到的编译器行为。

在高层次上:

  • MSVC 中有一个错误 (?),在某些明确定义的情况下,无法编译嵌套在类中的 函数 模板的完全显式特化模板。
  • 两个编译器总是可以编译嵌套在另一个类模板中的类模板的显式特化。但是,对于 MSVC 和 g++,“template”必须出现多少次的规则是不同的。因此,对于可移植代码,在某些情况下您必须使用条件编译。

我在这里给出的详细描述可能太简短了,普通读者无法理解,但我还是会尝试。

  • 通常,在声明/定义类模板成员的特化时(可能在嵌套类模板的深层链中),“模板”必须出现的次数等于“特化”的次数从“覆盖”正在声明的特化的最接近的类模板特化跳到正在声明的特化。
    • 将此称为“最后一跳规则”
    • 这适用于两种编译器上的所有类型的特殊成员(类/类模板、函数/函数模板、变量/变量模板和枚举),但有一个例外(见下文)
  • 用于声明/定义嵌套在另一个类模板中的 class 模板的特化(可能在嵌套类模板的深层链中)
    • 对于 MSVC:“模板”必须出现的次数是“最后一跳规则”
    • 对于 g++:这是“Las Hop 规则”不适用的一种情况。 (无论出于何种原因,我猜是 g++ 中的一个错误?)。在这种情况下,“模板”必须出现的次数等于被声明的特化的“深度”减去覆盖被声明的特化的模板类特化的总数。
  • 用于声明/定义嵌套在类模板中的 函数 模板的特化(可能在嵌套类模板的深层链中)
    • 对于 MSVC:在某些情况下无法编译。我推导出条件会编译,什么时候不会编译,但是这里描述的太复杂了。我猜 MSVC 中有一个错误 - g++ 总是有效的。当它起作用时,“模板”出现在“最后一跳规则”中的次数(对于两个编译器)。
    • 对于 g++:这总是有效的。 “模板”在“最后一跳规则”中出现的次数。

这里是一些示例代码,显示了在定义具有特定特化链的嵌套类模板时“template”必须出现多少次。这在 MSVC 和 g++ 上都可以编译(使用条件编译)。此代码不涉及嵌套的 function 模板。

#include <boost\predef.h>  // For conditional compilation

// Nested class templates, 3 deep.
template <int I1> struct T1
{
    template <int I2> struct T2
    {
        template <int I3> struct T3 {};
    };
};

// Specialization of the third level of class template.
// "template<>" appears three times here for both MSVC and g++ -
// in this case the rules for both compilers both yield 3.
// Note this class template specialization nests another 2 levels of class templates.
template <> template <> template<> struct T1<1>::T2<1>::T3<1>
{
    template <int I4> struct T4 
    {
        template <int I5> struct T5 {};
    };
};

// Specialize the class template contained in the class template specialization above.
// In this case, the number of times "template<>" must appear differs between MSVC and g++,
// so conditional compilation is used.
#if BOOST_COMP_GNUC
// According to the rule described for g++, "template<>" must appear 4 times: 
// (Overall specialization level of 5) - (1 covering specialization which is T1<1>::T2<1>::T3<1>) = 4
template <> template<> template<> template<> struct T1<1>::T2<1>::T3<1>::T4<1>::T5<1> 
#elif BOOST_COMP_MSVC
// MSVC uses the last hop specialization rule, so "template<>" must appear 2 times -
// because the closest covering specialization, T1<1>::T2<1>::T3<1>, is two hops back.
template <> template<> struct T1<1>::T2<1>::T3<1>::T4<1>::T5<1>    
#else
#error Unsupported compiler!
#endif
{ 
    //...
}

【讨论】:

  • 刚刚找到this。那么为什么 gcc 不抱怨。最好的,丹。
【解决方案2】:

这里的问题(就像在another question of yours 中一样)是,一旦为类模板(的整个)声明了显式特化,该特化在语法上就是一个普通类(尽管名称中包含标点符号):

template<int> struct A {
  void f();
};
template<int I> void A<I>::f() {}

// A specialization of only a member does use template<>:
template<> void A<0>::f() {/*...*/}

template<> struct A<1> {
  void g();
};
// A definition of a member of a specialization doesn't use template<>:
void A<1>::g() {}

对成员模板应用相同的逻辑产生

template<int> struct A {
  template<class> void f();
  template<> void f<void>() {}
};
template<int I> template<class T> void A<I>::f() {}

template<> template<class T> void A<0>::f() {/*...*/}
template<> template<> void A<-1>::f<short>() {/*...*/}
// template<int I> template<> void A<I>::f<int>() {/*...*/}

template<> struct A<1> {
  template<class> void g();
};
template<class T> void A<1>::g() {}
template<> void A<1>::g<char>() {/*...*/}

注释掉的可能性不起作用:您不能在该类模板外部专门化(非专门化)类模板的成员模板,尽管您可以在内部这样做模板(尽管 GCC 和 ICC 还没有实现)或完整的类模板专业化的成员模板。

如果在完全专业化的情况下,成员碰巧有相同的名字,这样的例子当然会有点违反直觉。如果存在编译器错误,它们也会更加令人困惑!

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-01-11
    • 1970-01-01
    • 1970-01-01
    • 2018-11-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-02-10
    相关资源
    最近更新 更多