?
條款28: 劃分全局名字空間
全局空間最大的問題在于它本身僅有一個(gè)。在大的軟件項(xiàng)目中，經(jīng)常會(huì)有不少人把他們定義的名字都放在這個(gè)單一的空間中，從而不可避免地導(dǎo)致名字沖突。例如，假設(shè)library1.h定義了一些常量，其中包括：
const double lib_version = 1.204;
類似的，library2.h也定義了：
const int lib_version = 3;
很顯然，如果某個(gè)程序想同時(shí)包含library1.h和library2.h就會(huì)有問題。對(duì)于這類問題，你除了嘴里罵幾句，或給作者發(fā)報(bào)復(fù)性郵件，或自己編輯頭文件來消除名字沖突外，也沒其它什么辦法。
但是，作為程序員，你可以盡力使自己寫的程序庫(kù)不給別人帶來這些問題。例如，可以預(yù)先想一些不大可能造成沖突的某種前綴，加在每個(gè)全局符號(hào)前。當(dāng)然得承認(rèn)，這樣組合起來的標(biāo)識(shí)符看起來不是那么令人舒服。
另一個(gè)比較好的方法是使用c++ namespace。namespace本質(zhì)上和使用前綴的方法一樣，只不過避免了別人總是看到前綴而已。所以，不要這么做：
const double sdmbook_version = 2.0;????? // 在這個(gè)程序庫(kù)中,
???????????????????????????????????????? // 每個(gè)符號(hào)以"sdm"開頭
class sdmhandle { ... };????????????????
sdmhandle& sdmgethandle();???????????? // 為什么函數(shù)要這樣聲明？
?????????????????????????????????????? // 參見條款47
而要這么做：
namespace sdm {
? const double book_version = 2.0;
? class handle { ... };
? handle& gethandle();
}
用戶于是可以通過三種方法來訪問這一名字空間里的符號(hào)：將名字空間中的所有符號(hào)全部引入到某一用戶空間；將部分符號(hào)引入到某一用戶空間；或通過修飾符顯式地一次性使用某個(gè)符號(hào)：
void f1()
{
? using namespace sdm;?????????? // 使得sdm中的所有符號(hào)不用加
???????????????????????????????? // 修飾符就可以使用
? cout << book_version;????????? // 解釋為sdm::book_version
? ...
? handle h = gethandle();??????? // handle解釋為sdm::handle,
???????????????????????????????? // gethandle解釋為sdm::gethandle
? ...???????????????????????????
}
void f2()
{
? using sdm::book_version;??????? // 使得僅book_version不用加
???????????????????????????????? // 修飾符就可以使用
? cout << book_version;?????????? // 解釋為
????????????????????????????????? // sdm::book_version
? ...
? handle h = gethandle();???????? // 錯(cuò)誤! handle和gethandle
????????????????????????????????? // 都沒有引入到本空間
? ...????????????????????????????
}
void f3()
{
? cout << sdm::book_version;????? // 使得book_version
????????????????????????????????? // 在本語(yǔ)句有效
? ...????????????????????????????
? double d = book_version;??????? // 錯(cuò)誤! book_version
????????????????????????????????? // 不在本空間
? handle h = gethandle();???????? // 錯(cuò)誤! handle和gethandle
????????????????????????????????? // 都沒有引入到本空間
? ...???????????????????????????
}
（有些名字空間沒有名字。這種沒命名的名字空間一般用于限制名字空間內(nèi)部元素的可見性。詳見條款m31。）
名字空間帶來的最大的好處之一在于：潛在的二義不會(huì)造成錯(cuò)誤（參見條款26）。所以，從多個(gè)不同的名字空間引入同一個(gè)符號(hào)名不會(huì)造成沖突（假如確實(shí)真的從不使用這個(gè)符號(hào)的話）。例如，除了名字空間sdm外，假如還要用到下面這個(gè)名字空間：
namespace acmewindowsystem {
? ...
? typedef int handle;
? ...
}
只要不引用符號(hào)handle，使用sdm和acmewindowsystem時(shí)就不會(huì)有沖突。假如真的要引用，可以明確地指明是哪個(gè)名字空間的handle：
void f()
{
? using namespace sdm;???????????????? // 引入sdm里的所有符號(hào)
? using namespace acmewindowsystem;??? // 引入acme里的所有符號(hào)
? ...????????????????????????????????? // 自由地引用sdm
?????????????????????????????????????? // 和acme里除handle之外
?????????????????????????????????????? // 的其它符號(hào)
? handle h;??????????????????????????? // 錯(cuò)誤! 哪個(gè)handle?
? sdm::handle h1;????????????????????? // 正確, 沒有二義
? acmewindowsystem::handle h2;???????? // 也沒有二義
? ...
}
假如用常規(guī)的基于頭文件的方法來做，只是簡(jiǎn)單地包含sdm.h和acme.h，這樣的話，由于handle有多個(gè)定義，編譯將不能通過。
名字空間的概念加入到c++標(biāo)準(zhǔn)的時(shí)間相對(duì)較晚，所以有些人會(huì)認(rèn)為它不太重要，可有可無。但這種想法是錯(cuò)誤的，因?yàn)閏++標(biāo)準(zhǔn)庫(kù)（參見條款49）里幾乎所有的東西都存在于名字空間std之中。這可能令你不以為然，但它卻以一種直接的方式影響到你：這就是為什么c++提供了那些看起來很有趣的、沒有擴(kuò)展名的頭文件，如<iostream>, <string>等。詳細(xì)介紹參見條款49。
由于名字空間的概念引入的時(shí)間相對(duì)較晚，有些編譯器可能不支持。就算是這樣，那也沒理由污染全局名字空間，因?yàn)榭梢杂胹truct來近似實(shí)現(xiàn)namespace?？梢赃@樣做：先創(chuàng)建一個(gè)結(jié)構(gòu)用以保存全局符號(hào)名，然后將這些全局符號(hào)名作為靜態(tài)成員放入結(jié)構(gòu)中：
// 用于模擬名字空間的一個(gè)結(jié)構(gòu)的定義
struct sdm {
? static const double book_version;
? class handle { ... };
? static handle& gethandle();
};
const double sdm::book_version = 2.0;????? // 靜態(tài)成員的定義
現(xiàn)在，如果有人想訪問這些全局符號(hào)名，只用簡(jiǎn)單地在它們前面加上結(jié)構(gòu)名作為前綴：
void f()
{
? cout << sdm::book_version;
? ...
? sdm::handle h = sdm::gethandle();
? ...
}
但是，如果全局范圍內(nèi)實(shí)際上沒有名字沖突，用戶就會(huì)覺得加修飾符麻煩而多余。幸運(yùn)的是，還是有辦法來讓用戶選擇使用它們或忽略它們。
對(duì)于類型名，可以用類型定義（typedef）來顯式地去掉空間引用。例如，假設(shè)結(jié)構(gòu)s（模擬的名字空間）內(nèi)有個(gè)類型名t，可以這樣用typedef來使得t成為s::t的同義詞：
typedef sdm::handle handle;
對(duì)于結(jié)構(gòu)中的每個(gè)（靜態(tài)）對(duì)象x，可以提供一個(gè)（全局）引用x，并初始化為s::x：
const double& book_version = sdm::book_version;
老實(shí)說，如果讀了條款47，你就會(huì)不喜歡定義一個(gè)象book_version這樣的非局部靜態(tài)對(duì)象。（你就會(huì)用條款47中所介紹的函數(shù)來取代這樣的對(duì)象）
處理函數(shù)的方法和處理對(duì)象一樣，但要注意，即使定義函數(shù)的引用是合法的，但代碼的維護(hù)者會(huì)更喜歡你使用函數(shù)指針：
sdm::handle& (* const gethandle)() =????? // gethandle是指向sdm::gethandle
? sdm::gethandle;???????????????????????? // 的const 指針 (見條款21)
注意gethandle是一個(gè)常指針。因?yàn)槟惝?dāng)然不想讓你的用戶將它指向別的什么東西，而不是sdm::gethandle，對(duì)不對(duì)？
（如果真想知道怎么定義一個(gè)函數(shù)的引用，看看下面：
sdm::handle& (&gethandle)() =????? // gethandle是指向
? sdm::gethandle;????????????????? // sdm::gethandle的引用
我個(gè)人認(rèn)為這樣的做法也很好，但你可能以前從沒見到過。除了初始化的方式外，函數(shù)的引用和函數(shù)的常指針在行為上完全相同，只是函數(shù)指針更易于理解。）
有了上面的類型定義和引用，那些不會(huì)遭遇全局名字沖突的用戶就會(huì)使用沒有修飾符的類型和對(duì)象名；相反，那些有全局名字沖突的用戶就會(huì)忽略類型和引用的定義，代之以帶修飾符的符號(hào)名。還要注意的是，不是所有用戶都想使用這種簡(jiǎn)寫名，所以要把類型定義和引用放在一個(gè)單獨(dú)的頭文件中，不要把它和（模擬namespace的）結(jié)構(gòu)的定義混在一起。
struct是namespace的很好的近似，但實(shí)際上還是相差很遠(yuǎn)。它在很多方面很欠缺，其中很明顯的一點(diǎn)是對(duì)運(yùn)算符的處理。如果運(yùn)算符被定義為結(jié)構(gòu)的靜態(tài)成員，它就只能通過函數(shù)調(diào)用來使用，而不能象常規(guī)的運(yùn)算符所設(shè)計(jì)的那樣，可以通過自然的中綴語(yǔ)法來使用：
// 定義一個(gè)模擬名字空間的結(jié)構(gòu)，結(jié)構(gòu)內(nèi)部包含widgets的類型
// 和函數(shù)。widgets對(duì)象支持operator+進(jìn)行加法運(yùn)算
struct widgets {
? class widget { ... };
? // 參見條款21：為什么返回const
? static const widget operator+(const widget& lhs,
??????????????????????????????? const widget& rhs);
? ...
};
// 為上面所述的widge和operator+
// 建立全局（無修飾符的）名稱
typedef widgets::widget widget;
const widget (* const operator+)(const widget&,??????? // 錯(cuò)誤!
???????????????????????????????? const widget&);?????? // operator+不能是指針名
?
widget w1, w2, sum;
sum = w1 + w2;?????????????????????????? // 錯(cuò)誤! 本空間沒有聲明
???????????????????????????????????????? // 參數(shù)為widgets 的operator+
sum = widgets::operator+(w1, w2);??????? // 合法, 但不是
???????????????????????????????????????? // "自然"的語(yǔ)法
正因?yàn)檫@些限制，所以一旦編譯器支持，就要盡早使用真正的名字空間。
