首頁猿問加前綴的雙冒號“：&r...

加前綴的雙冒號“：”的含義是什么？

C++

桃花長相依 2019-12-17 13:12:26

加前綴的雙冒號“：”的含義是什么？我在一個必須修改的類中找到了這一行代碼：::Configuration * tmpCo = m_configurationDB;//pointer to current db我不知道類名前面的雙冒號到底是什么意思。如果沒有，我會讀到：宣布tmpCo作為指向類的對象的指針。Configuration..但這兩個冒號讓我很困惑。我還發(fā)現(xiàn)：typedef ::config::set ConfigSet;

查看完整描述

3 回答

萬千封印

TA貢獻1891條經(jīng)驗獲得超3個贊

這確保解析發(fā)生在全局命名空間中，而不是從當前所在的名稱空間開始。例如，如果您有兩個不同的類Configuration因此：

class Configuration; // class 1, in global namespacenamespace MyApp{
    class Configuration; // class 2, different from class 1
    function blah()
    {
        // resolves to MyApp::Configuration, class 2
        Configuration::doStuff(...) 
        // resolves to top-level Configuration, class 1
        ::Configuration::doStuff(...)
    }}

基本上，它允許您遍歷全局命名空間，因為在本例中，您的名稱可能會被另一個名稱空間內的新定義所破壞。MyApp.

反對回復 2019-12-19

繁花如伊

TA貢獻2012條經(jīng)驗獲得超12個贊

這個::運算符稱為作用域解析運算符，它就是這樣做的，它解析作用域.因此，通過在一個類型名的前綴加上這個前綴，它會告訴您的編譯器查看該類型的全局命名空間。

例子：

int count = 0;int main(void) {
  int count = 0;
  ::count = 1;  // set global count to 1
  count = 2;    // set local count to 2
  return 0;}

反對回復 2019-12-19

繁星點點滴滴

TA貢獻1803條經(jīng)驗獲得超3個贊

已經(jīng)有很多合理的答案了。我將加入一個類比，這可能會對一些讀者有所幫助。::非常類似于文件系統(tǒng)目錄分隔符‘/‘，在搜索您想要運行的程序的路徑時。考慮：

/path/to/executable

這是非常顯式的-只有在文件系統(tǒng)樹中的確切位置上的可執(zhí)行文件才能與此規(guī)范相匹配，而不管實際的路徑是什么。同樣的.。

::std::cout

.在C+命名空間“樹”中同樣顯式。

與這些絕對路徑相比，您可以配置良好的UNIXshell(例如，茲什)解決相對當前目錄下的路徑或PATH環(huán)境變量，所以如果PATH=/usr/bin:/usr/local/bin，而你“在”/tmp然后.。

X11/xterm

.很樂意跑/tmp/X11/xterm如果被發(fā)現(xiàn)，否則/usr/bin/X11/xterm不然的話/usr/local/bin/X11/xterm..類似地，假設您在一個名為X，并且有一個“using namespace Y“實際上，那么.

std::cout

.可以在任何一個::X::std::cout, ::std::cout, ::Y::std::cout，可能還有其他地方參數(shù)相關查找(ADL，又名Koenig查找)所以，只有::std::cout非常明確地說明了您指的是哪個對象，但幸運的是，沒有一個頭腦正常的人會創(chuàng)建自己的類/結構或名稱空間，名為“std“，也沒有什么叫”cout“，所以在實踐中只使用std::cout都沒問題。

值得注意的差異:

1)shell傾向于使用PATH，而C+在模棱兩可的情況下會出現(xiàn)編譯器錯誤。

2)在C+中，沒有任何前導作用域的名稱可以在當前命名空間中匹配，而大多數(shù)UNIXshell只能在.在PATH.

3)C+總是搜索全局命名空間(比如/含蓄地PATH).

關于名稱空間與符號明示性的一般性討論

使用絕對::abc::def::...“路徑”有時有助于將您與您正在使用的任何其他名稱空間隔離開來，這些名稱空間是庫的客戶端代碼也使用的內容的一部分，但實際上無法控制其內容，甚至是其他庫。另一方面，它還更緊密地將您與符號的現(xiàn)有“絕對”位置結合在一起，并且您忽略了名稱空間中隱式匹配的優(yōu)點：耦合更少，代碼在命名空間之間更容易移動，以及更簡潔、更易讀的源代碼。

和很多事情一樣，這是一種平衡的行為。C+標準在std::它不那么“獨特”cout，程序員可能會在他們的代碼中使用完全不同的東西。merge, includes, fill, generate, exchange, queue, toupper, max)。兩個不相關的非標準庫使用相同的標識符的幾率要高得多，因為作者通常不知道或不太了解對方。庫-包括C+標準庫-隨著時間的推移而改變它們的符號。所有這些都可能在重新編譯舊代碼時造成歧義，特別是在大量使用using namespace在這個空間里你能做的最糟糕的事情就是允許using namespace在標頭中，可以轉義標頭的作用域，因此任意數(shù)量的直接和間接客戶端代碼無法自行決定使用哪些命名空間以及如何管理歧義。