Question

namespace A
{
    class B
    {
    public:
        B(int);
    };
}

namespace C
{
    class D
    {
        static const ::A::B b;
    };
}

const ::A::B ::C::D::b(0);      // #1
// const ::A::B C::D::b(0);     // #2
// const ::A::B (::C::D::b)(0); // #3

选项＃1无法编译。现在我已经考虑了一段时间，我很确定编译器认为“B”和“:: C”之间的空白是无关紧要的，所以它试图在“B”中找到一个成员“C”。如果发生了这种情况，我需要一些方法来说服编译器这些是两个独立的限定名称。

选项＃2和＃3似乎都在一个非常小的测试中工作。＃3似乎不太容易受到名称冲突的影响，因为它更有资格。切换到＃3对我来说也更容易一些。所以我倾向于＃3，但看起来很奇怪。

有没有强烈的理由偏爱一个而不是另一个？我可以期望两者在其他编译器上正常工作吗？有没有比任何一个更好的解决方案？就此而言，我是否正确＃1为什么会失败？

可能不必要的细节

启发这个问题的代码是由我编写的源代码生成器输出的。标识符是从生成器的输入派生的，因此我担心名称冲突，特别是范围之间的无意遮蔽，生成器无法检测到。所以，我编写了生成器来尽可能完全限定每个标识符。
我正在编译VC2010。
我故意不使用C ++ 0X功能，因为我希望代码可以移植到某些较旧的编译器。
具体的编译错误是“错误C3083：'C'：'::'左边的符号必须是类型”

Answer 1

我很确定编译器认为“B”和“:: C”之间的空白是无关紧要的，所以它试图在“B”中找到一个成员“C”

这是完全正确的。

是否有任何理由更喜欢一个而不是另一个？我可以期望两者在其他编译器上正常工作吗？

选项＃3看起来很好（并且符合要求）;也就是说，如果你真的坚持这个相当愚蠢的要求。：）

我自己用它来结束a blog post on a very similar "issue"。

完全限定的静态成员定义将无法编译

1 个答案: