完全限定的靜態成員定義不會編譯

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’：在符號左側的‘::’必須是一種」

來源

2012-01-10 George Compton

**相關：** http://kera.name/articles/2011/02/befriending-your-parser/ – 2012-01-10 00:11:33

我敢肯定，編譯器認爲該空白之間「B」和「:: C」微不足道，所以它試圖找到一個成員「C」內「B」

這是正確的。

是否有強烈的理由相對於另一方偏好？我可以期待在其他編譯器上正常工作嗎？

選項＃3對我來說看起來很好（並且是兼容的）;也就是說，如果你真的真的堅持這個相當愚蠢的要求。 :)

我自己用它來得出結論a blog post on a very similar "issue"。

來源

2012-01-10 00:09:30

謝謝。完全限定並不是「安全」的默認要求。在生成的代碼中還有一些其他地方需要一些資格來繞過陰影。在任何地方生成完全限定名稱比僅僅選擇性限定某些事物更容易。如果資格過高導致我有更多問題，我可能會重新考慮，但現在，我認爲我仍然滿意於權衡。當然，這隻適用於生成的代碼;我通常不會不必要地限制我手寫的代碼中的任何內容。 – 2012-01-10 18:14:33

@George：聽起來不錯。 – 2012-01-10 18:42:28

完全限定的靜態成員定義不會編譯

回答

相關問題