2. 一組聲明的鏈接規(guī)范，比如：

對我們之前的例子而言，如果我們把頭文件my_handle.h的內容改成：

然后使用C++編譯器重新編譯my_handle_client.cpp，所生成目標文件my_handle_client.o中的符號表就變?yōu)椋?/span>

從中我們可以看出，此時，用extern "C" 修飾了的聲明，其生成的符號和C語言編譯器生成的符號保持了一致。這樣，當你再次把my_handle.o和my_handle_client.o放在一起鏈接的時候，就不會再有之前的“符號未定義”錯誤了。

但此時，如果你重新編譯my_handle.c，C語言編譯器將會報告“語法錯誤”，因為extern"C"是C++的語法，C語言編譯器不認識它。此時，可以按照我們之前已經討論的，使用宏__cplusplus來識別C和C++編譯器。修改后的my_handle.h的代碼如下：

小心門后的未知世界

我們先來看一個例子，現(xiàn)有a.h，b.h，c.h以及foo.cpp，其中foo.cpp包含c.h，c.h包含b.h，b.h包含a.h，如下：

現(xiàn)使用C++編譯器的預處理選項來編譯foo.cpp，得到下面的結果：

正如你看到的，當你把#include指令放置在extern "C" { }里的時候，則會造成extern "C" { } 的嵌套。這種嵌套是被C++規(guī)范允許的。當嵌套發(fā)生時，以最內層的嵌套為準。比如在下面代碼中，函數(shù)foo會使用C++的鏈接規(guī)范，而函數(shù)bar則會使用C的鏈接規(guī)范。

如果能夠保證一個C語言頭文件直接或間接依賴的所有頭文件也都是C語言的，那么按照C++語言規(guī)范，這種嵌套應該不會有什么問題。但具體到某些編譯器的實現(xiàn)，比如MSVC2005，卻可能由于 extern "C" { } 的嵌套過深而報告錯誤。不要因此而責備微軟，因為就這個問題而言，這種嵌套是毫無意義的。你完全可以通過把#include指令放置在extern "C" { }的外面來避免嵌套。拿之前的例子來說，如果我們把各個頭文件的 #include 指令都移到extern "C" { } 之外，然后使用C++編譯器的預處理選項來編譯foo.cpp，就會得到下面的結果：

這樣的結果肯定不會引起編譯問題的結果——即便是使用MSVC。

把 #include 指令放置在extern "C" { }里面的另外一個重大風險是，你可能會無意中改變一個函數(shù)聲明的鏈接規(guī)范。比如：有兩個頭文件a.h，b.h，其中b.h包含a.h，如下：

按照a.h作者的本意，函數(shù)foo是一個C++自由函數(shù)，其鏈接規(guī)范為"C++"。但在b.h中，由于#include "a.h"被放到了extern "C" { }的內部，函數(shù)foo的鏈接規(guī)范被不正確地更改了。

由于每一條 #include 指令后面都隱藏這一個未知的世界，除非你刻意去探索，否則你永遠都不知道，當你把一條條#include指令放置于extern "C" { }里面的時候，到底會產生怎樣的結果，會帶來何種的風險。或許你會說，“我可以去查看這些被包含的頭文件，我可以保證它們不會帶來麻煩”。但，何必呢？畢竟，我們完全可以不必為不必要的事情買單，不是嗎？

Q&A

A: 正像這個世界的大多數(shù)規(guī)則一樣，總會存在特殊情況。

有時候，你可能利用頭文件機制“巧妙”的解決一些問題。比如，#pragma pack的問題。這些頭文件和常規(guī)的頭文件作用是不一樣的，它們里面不會放置C的函數(shù)聲明或者變量定義，鏈接規(guī)范不會對它們的內容產生影響。這種情況下，你可以不必遵守這些規(guī)則。

更加一般的原則是，在你明白了這所有的原理之后，只要你明白自己在干什么，那就去做吧。

Q: 你只說了不應該放入extern "C"的，但什么可以放入呢？

A: 鏈接規(guī)范僅僅用于修飾函數(shù)和變量，以及函數(shù)類型。所以，嚴格的講，你只應該把這三種對象放置于extern "C"的內部。

但，你把C語言的其它元素，比如非函數(shù)類型定義（結構體，枚舉等）放入extern "C"內部，也不會帶來任何影響。更不用說宏定義預處理指令了。

所以，如果你更加看重良好組織和管理的習慣，你應該只在必須使用extern "C"聲明的地方使用它。即使你比較懶惰，絕大多數(shù)情況下，把一個頭件自身的所有定義和聲明都放置在extern"C"里面也不會有太大的問題。

Q: 如果一個帶有函數(shù)/變量聲明的C頭文件里沒有extern "C"聲明怎么辦？

A: 如果你可以判斷，這個頭文件永遠不可能讓C++代碼來使用，那么就不要管它。

但現(xiàn)實是，大多數(shù)情況下，你無法準確的推測未來。你在現(xiàn)在就加上這個extern "C"，這花不了你多少成本，但如果你現(xiàn)在沒有加，等到將來這個頭文件無意中被別人的C++程序包含的時候，別人很可能需要更高的成本來定位錯誤和修復問題。

Q: 如果我的C+ +程序想包含一個C頭文件a . h，它的內容包含了C的函數(shù)/變量聲明，但它們卻沒有使用extern "C"鏈接規(guī)范，該怎么辦？

A: 在a.h里面加上它。

某些人可能會建議你，如果a.h沒有extern "C"，而b.cpp包含了a.h，可以在b.cpp里加上 ：

這是一個邪惡的方案，原因在之前我們已經闡述。但值得探討的是，這種方案這背后卻可能隱含著一個假設，即我們不能修改a.h。不能修改的原因可能來自兩個方面：

• 頭文件代碼屬于其它團隊或者第三方公司，你沒有修改代碼的權限；

• 雖然你擁有修改代碼的權限，但由于這個頭文件屬于遺留系統(tǒng)，冒然修改可能會帶來不可預知的問題。

對于第一種情況，不要試圖自己進行workaround，因為這會給你帶來不必要的麻煩。正確的解決方案是，把它當作一個bug，發(fā)送缺陷報告給相應的團隊 或第三方公司。如果是自己公司的團隊或你已經付費的第三方公司，他們有義務為你進行這樣的修改。如果他們不明白這件事情的重要性，告訴他們。如果這些頭文 件屬于一個免費開源軟件，自己進行正確的修改，并發(fā)布patch給其開發(fā)團隊。

在第二種情況下，你需要拋棄掉這種不必要的安全意識。因為，首先，對于大多數(shù)頭文件而言，這種修改都不是一種復雜的，高風險的修改，一切都在可控的范圍之 內；其次，如果某個頭文件混亂而復雜，雖然對于遺留系統(tǒng)的哲學應該是：“在它還沒有帶來麻煩之前不要動它”，但現(xiàn)在麻煩已經來了，逃避不如正視，所以上策 是，將其視作一個可以整理到干凈合理狀態(tài)的良好機會。

Q: 我們代碼中關于extern "C"的寫法如下，這正確嗎?

A: 不確定。

按照C++的規(guī)范定義，__cplusplus 的值應該被定義為199711L，這是一個非零的值；盡管某些編譯器并沒有按照規(guī)范來實現(xiàn)，但仍然能夠保證__cplusplus的值為非零——至少我到目前為止還沒有看到哪款編譯器將其實現(xiàn)為0。這種情況下，#if __cplusplus ... #endif完全是冗余的。

但，C++編譯器的廠商是如此之多，沒有人可以保證某款編譯器，或某款編譯器的早期版本沒有將__cplusplus的值定義為0。但即便如此，只要能夠保證宏__cplusplus只在C++編譯器中被預先定義 ，那么，僅僅使用#ifdef __cplusplus ? #endif就足以確保意圖的正確性；額外的使用#if __cplusplus ... #endif反而是錯誤的。

只有在這種情況下：即某個廠商的C語言和C++語言編譯器都預先定義了__cplusplus ，但通過其值為0和非零來進行區(qū)分，使用#if __cplusplus ... #endif才是正確且必要的。

既然現(xiàn)實世界是如此復雜，你就需要明確自己的目標，然后根據目標定義相應的策略。比如：如果你的目標是讓你的代碼能夠使用幾款主流的、正確遵守了規(guī)范的編譯器進行編譯，那么你只需要簡單的使用#ifdef __cplusplus ... #endif就足夠了。

但如果你的產品是一個雄心勃勃的，試圖兼容各種編譯器的（包括未知的）跨平臺產品， 我們可能不得不使用下述方法來應對各種情況 ，其中__ALIEN_C_LINKAGE__是為了標識那些在C和C++編譯中都定義了__cplusplus宏的編譯器。

這應該可以工作，但在每個頭文件中都寫這么一大串，不僅有礙觀瞻，還會造成一旦策略進行修改，就會到處修改的狀況。違反了DRY(Don't Repeat Yourself)原則，你總要為之付出額外的代價。解決它的一個簡單方案是，定義一個特定的頭文件——比如clinkage.h，在其中增加這樣的定義：

以下舉例中c的函數(shù)聲明和定義分別在cfun.h 和 cfun.c 中，函數(shù)打印字符串 “this is c fun call”，c++函數(shù)聲明和定義分別在cppfun.h 和 cppfun.cpp中，函數(shù)打印字符串 "this is cpp fun call", 編譯環(huán)境vc2010.

C++ 調用 C 的方法

cppfun.cpp 如下：

?