http://blog.csdn.net/u013059266/article/details/46998703
import <Availability.h>
ifdef __cplusplus
define UIKIT_EXTERN extern "C" attribute((visibility("default")))
else
define UIKIT_EXTERN extern attribute((visibility ("default")))
endif
defineUIKIT_STATIC_INLINE static inline
我的總結(jié)主要是為了跨平臺使用代碼 extern “C”,就是為了支持C的庫。蘋果 api 中用的比較多。
類似 UIKIT_EXTERN,對應還有FOUNDATION_EXTERN
if defined(__cplusplus)
define FOUNDATION_EXTERNextern "C"
else
define FOUNDATION_EXTERNextern
endif
部分使用，不是很懂的樣子。
UIKIT_EXTERNNSString *const UIDeviceOrientationDidChangeNotification; // 設備旋轉(zhuǎn)
UIKIT_EXTERNNSString *const UIDeviceBatteryStateDidChangeNotification; // 電池狀態(tài)
UIKIT_EXTERNNSString *const UIDeviceBatteryLevelDidChangeNotification; // 電池電量
UIKIT_EXTERNNSString *const UIDeviceProximityStateDidChangeNotification; // 近距離傳感器
1、UIKitt提供中幾個圖像上下文（Graphics contex）的函數(shù),此處忽略pdf相關(guān)的處理
UIKIT_EXTERNCGContextRef UIGraphicsGetCurrentContext(void);
UIKIT_EXTERN voidUIGraphicsPushContext(CGContextRef context);
UIKIT_EXTERN voidUIGraphicsPopContext(void);
UIKIT_EXTERN voidUIRectFillUsingBlendMode(CGRect rect, CGBlendMode blendMode);
UIKIT_EXTERN voidUIRectFill(CGRect rect);
UIKIT_EXTERN voidUIRectFrameUsingBlendMode(CGRect rect, CGBlendMode blendMode);
UIKIT_EXTERN voidUIRectFrame(CGRect rect);
UIKIT_EXTERN voidUIRectClip(CGRect rect);
// UIImage context
UIKIT_EXTERN void UIGraphicsBeginImageContext(CGSize size);
UIKIT_EXTERN void UIGraphicsBeginImageContextWithOptions(CGSize size, BOOL opaque, CGFloatscale) NS_AVAILABLE_IOS(4_0);
UIKIT_EXTERN UIImage*UIGraphicsGetImageFromCurrentImageContext(void);
UIKIT_EXTERN void UIGraphicsEndImageContext(void);
各種解釋：以下轉(zhuǎn)載
一般用于將C++代碼以標準C形式輸出（即以C的形式被調(diào)用），這是因為C++雖然常被認為是C的超集，但是C++的編譯器還是與C的編譯器不同的。C中調(diào)用C++中的代碼這樣定義會是安全的。
一般的考慮跨平臺使用方法如下：
ifdefined(__cplusplus)||defined(c_plusplus) //跨平臺定義方法
extern "C"{
endif
//... 正常的聲明段
ifdefined(__cplusplus)||defined(c_plusplus)
}
endif
簡單的用在windows下可以如下定義:
ifdef __cplusplus
extern "C"{
//... 正常的聲明段
}
endif
某一網(wǎng)文：
ifdef__cplusplus是什么意思？
時常在cpp的代碼之中看到這樣的代碼:
ifdef__cplusplus
extern"C"{
endif
//一段代碼
ifdef__cplusplus
}
endif
這樣的代碼到底是什么意思呢？
首先，__cplusplus是cpp中的自定義宏，那么定義了這個宏的話表示這是一段cpp的代碼，也就是說，上面的代碼的含義是:
如果這是一段cpp的代碼，那么加入extern"C"{和}處理其中的代碼。
要明白為何使用extern"C"，還得從cpp中對函數(shù)的重載處理開始說起。在c++中，為了支持重載機制，在編譯生成的匯編碼中，要對函數(shù)的名字進行一些處理，加入比如函數(shù)的返回類型等等.而在C中，只是簡單的函數(shù)名字而已，不會加入其他的信息.也就是說:C++和C對產(chǎn)生的函數(shù)名字的處理是不一樣的.
比如下面的一段簡單的函數(shù)，我們看看加入和不加入extern"C"產(chǎn)生的匯編代碼都有哪
些變化:
intf(void)
{
return1;
}
在加入extern"C"的時候產(chǎn)生的匯編代碼是:
.file"test.cxx"
.text
.align2
.globl_f
.def_f;.scl2;.type32;.endef
_f:
pushl%ebp
movl%esp，%ebp
movl$1，%eax
popl%ebp
ret
但是不加入了extern"C"之后
.file"test.cxx"
.text
.align2
.globl__Z1fv
.def__Z1fv;.scl2;.type 32;.endef
__Z1fv:
pushl%ebp
movl%esp，%ebp
movl$1，%eax
popl%ebp
ret
兩段匯編代碼同樣都是使用gcc-S命令產(chǎn)生的，所有的地方都是一樣的，唯獨是產(chǎn)生的
函數(shù)名，一個是_f，一個是__Z1fv。
明白了加入與不加入extern"C"之后對函數(shù)名稱產(chǎn)生的影響，我們繼續(xù)我們的討論:為什
么需要使用extern"C"呢？C++之父在設計C++之時，考慮到當時已經(jīng)存在了大量的C代碼，
為了支持原來的C代碼和已經(jīng)寫好C庫，需要在C++中盡可能的支持C，而extern"C"就是
其中的一個策略。
試想這樣的情況:一個庫文件已經(jīng)用C寫好了而且運行得很良好，這個時候我們需要使
用這個庫文件，但是我們需要使用C++來寫這個新的代碼。如果這個代碼使用的是C++的
方式鏈接這個C庫文件的話，那么就會出現(xiàn)鏈接錯誤.我們來看一段代碼:首先，我們使用C
的處理方式來寫一個函數(shù)，也就是說假設這個函數(shù)當時是用C寫成的:
//f1.c
extern"C"
{
voidf1()
{
return;
}
}
編譯命令是:gcc-cf1.c-of1.o產(chǎn)生了一個叫f1.o的庫文件。再寫一段代碼調(diào)用這個f1
函數(shù):
//test.cxx
//這個extern表示f1函數(shù)在別的地方定義，這樣可以通過
//編譯，但是鏈接的時候還是需要
//鏈接上原來的庫文件.
externvoidf1();
intmain()
{
f1();
return0;
}
通過gcc-ctest.cxx-otest.o產(chǎn)生一個叫test.o的文件。然后，我們使用gcctest.of1.o來
鏈接兩個文件，可是出錯了，錯誤的提示是:
test.o(.text+0x1f):test.cxx:undefinereferenceto'f1()'
也就是說，在編譯test.cxx的時候編譯器是使用C++的方式來處理f1()函數(shù)的，但是實
際上鏈接的庫文件卻是用C的方式來處理函數(shù)的，所以就會出現(xiàn)鏈接過不去的錯誤:因為鏈
接器找不到函數(shù)。
因此，為了在C++代碼中調(diào)用用C寫成的庫文件，就需要用extern"C"來告訴編譯器:
這是一個用C寫成的庫文件，請用C的方式來鏈接它們。
比如，現(xiàn)在我們有了一個C庫文件，它的頭文件是f.h，產(chǎn)生的lib文件是f.lib，那么我
們?nèi)绻贑++中使用這個庫文件，我們需要這樣寫:
extern"C"
{
include"f.h"
}
回到上面的問題，如果要改正鏈接錯誤，我們需要這樣子改寫test.cxx:
extern"C"
{
externvoidf1();
}
intmain()
{
f1();
return0;
}
重新編譯并且鏈接就可以過去了.
總結(jié)
C和C++對函數(shù)的處理方式是不同的.extern"C"是使C++能夠調(diào)用C寫作的庫文件的一
個手段，如果要對編譯器提示使用C的方式來處理函數(shù)的話，那么就要使用extern"C"來說
明。
另一篇文章：
ifdef__cplusplus
ifdef__cplusplus倒底是什么意思？
時常在cpp的代碼之中看到這樣的代碼:
ifdef__cplusplus
extern "C" {
endif
//一段代碼
ifdef__cplusplus
}
endif
這樣的代碼到底是什么意思呢？首先，__cplusplus是cpp中的自定義宏，那么定義了這個宏的話表示這是一段cpp的代碼，也就是說，上面的代碼的含義是:如果這是一段cpp的代碼，那么加入extern "C"{和}處理其中的代碼。
要明白為何使用extern "C"，還得從cpp中對函數(shù)的重載處理開始說起。在c++中，為了支持重載機制，在編譯生成的匯編碼中，要對函數(shù)的名字進行一些處理，加入比如函數(shù)的返回類型等等.而在C中，只是簡單的函數(shù)名字而已，不會加入其他的信息.也就是說:C++和C對產(chǎn)生的函數(shù)名字的處理是不一樣的.
比如下面的一段簡單的函數(shù)，我們看看加入和不加入extern"C"產(chǎn)生的匯編代碼都有哪些變化:
int f(void)
{
return 1;
}
在加入extern "C"的時候產(chǎn)生的匯編代碼是:
.file "test.cxx"
.text
.align 2
.globl _f
.def _f; .scl 2; .type 32; .endef
_f:
pushl %ebp
movl %esp， %ebp
movl $1， %eax
popl %ebp
ret
但是不加入了extern "C"之后
.file "test.cxx"
.text
.align 2
.globl __Z1fv
.def __Z1fv; .scl 2; .type 32; .endef
__Z1fv:
pushl %ebp
movl %esp， %ebp
movl $1， %eax
popl %ebp
ret
兩段匯編代碼同樣都是使用gcc -S命令產(chǎn)生的，所有的地方都是一樣的，唯獨是產(chǎn)生的函數(shù)名，一個是_f，一個是__Z1fv。
明白了加入與不加入extern "C"之后對函數(shù)名稱產(chǎn)生的影響，我們繼續(xù)我們的討論:為什么需要使用extern "C"呢？C++之父在設計C++之時，考慮到當時已經(jīng)存在了大量的C代碼，為了支持原來的C代碼和已經(jīng)寫好C庫，需要在C++中盡可能的支持C，而extern"C"就是其中的一個策略。
試想這樣的情況:一個庫文件已經(jīng)用C寫好了而且運行得很良好，這個時候我們需要使用這個庫文件，但是我們需要使用C++來寫這個新的代碼。如果這個代碼使用的是C++的方式鏈接這個C庫文件的話，那么就會出現(xiàn)鏈接錯誤.我們來看一段代碼:首先，我們使用C的處理方式來寫一個函數(shù)，也就是說假設這個函數(shù)當時是用C寫成的:
//f1.c
extern "C"
{
void f1()
{
return;
}
}
編譯命令是:gcc -c f1.c -o f1.o產(chǎn)生了一個叫f1.o的庫文件。再寫一段代碼調(diào)用這個f1函數(shù):
// test.cxx
//這個extern表示f1函數(shù)在別的地方定義，這樣可以通過
//編譯，但是鏈接的時候還是需要
//鏈接上原來的庫文件.
extern void f1();
int main()
{
f1();
return 0;
}
通過gcc -c test.cxx -o test.o產(chǎn)生一個叫test.o的文件。然后，我們使用gcc test.o f1.o來鏈接兩個文件，可是出錯了，錯誤的提示是:
test.o(.text + 0x1f):test.cxx: undefinereference to 'f1()'
也就是說，在編譯test.cxx的時候編譯器是使用C++的方式來處理f1()函數(shù)的，但是實際上鏈接的庫文件卻是用C的方式來處理函數(shù)的，所以就會出現(xiàn)鏈接過不去的錯誤:因為鏈接器找不到函數(shù)。
因此，為了在C++代碼中調(diào)用用C寫成的庫文件，就需要用extern "C"來告訴編譯器:這是一個用C寫成的庫文件，請用C的方式來鏈接它們。
比如，現(xiàn)在我們有了一個C庫文件，它的頭文件是f.h，產(chǎn)生的lib文件是f.lib，那么我們?nèi)绻贑++中使用這個庫文件，我們需要這樣寫:
extern "C"
{
include "f.h"
}
回到上面的問題，如果要改正鏈接錯誤，我們需要這樣子改寫test.cxx:
extern "C"
{
extern void f1();
}
int main()
{
f1();
return 0;
}
重新編譯并且鏈接就可以過去了.
總結(jié)
C和C++對函數(shù)的處理方式是不同的.extern "C"是使C++能夠調(diào)用C寫作的庫文件的一個手段，如果要對編譯器提示使用C的方式來處理函數(shù)的話，那么就要使用extern "C"來說明。
1.引言
C++語言的創(chuàng)建初衷是“a better C”，但是這并不意味著C++中類似C語言的全局變量和函數(shù)所采用的編譯和連接方式與C語言完全相同。作為一種欲與C兼容的語言，C++保留了一部分過程式語言的特點（被世人稱為“不徹底地面向?qū)ο蟆保?，因而它可以定義不屬于任何類的全局變量和函數(shù)。但是，C++畢竟是一種面向?qū)ο蟮某绦蛟O計語言，為了支持函數(shù)的重載，C++對全局函數(shù)的處理方式與C有明顯的不同。
2.從標準頭文件說起
某企業(yè)曾經(jīng)給出如下的一道面試題：
面試題
為什么標準頭文件都有類似以下的結(jié)構(gòu)？
ifndef __INCvxWorksh
define __INCvxWorksh
ifdef__cplusplus
extern "C" {
endif
ifdef__cplusplus
}
endif
endif
分析
顯然，頭文件中的編譯宏“#ifndef __INCvxWorksh、#define __INCvxWorksh、#endif”的作用是防止該頭文件被重復引用。
那么
ifdef__cplusplus
extern "C" {
endif
ifdef__cplusplus
}
endif
的作用又是什么呢？我們將在下文一一道來。
3.深層揭密extern "C"
extern "C" 包含雙重含義，從字面上即可得到：首先，被它修飾的目標是“extern”的；其次，被它修飾的目標是“C”的。讓我們來詳細解讀這兩重含義。
（1）被extern "C"限定的函數(shù)或變量是extern類型的；
extern是C/C++語言中表明函數(shù)和全局變量作用范圍（可見性）的關(guān)鍵字，該關(guān)鍵字告訴編譯器，其聲明的函數(shù)和變量可以在本模塊或其它模塊中使用。記住，下列語句：
extern int a;
僅僅是一個變量的聲明，其并不是在定義變量a，并未為a分配內(nèi)存空間。變量a在所有模塊中作為一種全局變量只能被定義一次，否則會出現(xiàn)連接錯誤。
通常，在模塊的頭文件中對本模塊提供給其它模塊引用的函數(shù)和全局變量以關(guān)鍵字extern聲明。例如，如果模塊B欲引用該模塊A中定義的全局變量和函數(shù)時只需包含模塊A的頭文件即可。這樣，模塊B中調(diào)用模塊A中的函數(shù)時，在編譯階段，模塊B雖然找不到該函數(shù)，但是并不會報錯；它會在連接階段中從模塊 A編譯生成的目標代碼中找到此函數(shù)。
與extern對應的關(guān)鍵字是static，被它修飾的全局變量和函數(shù)只能在本模塊中使用。因此，一個函數(shù)或變量只可能被本模塊使用時，其不可能被extern “C”修飾。
（2）被extern "C"修飾的變量和函數(shù)是按照C語言方式編譯和連接的；
未加extern “C”聲明時的編譯方式
首先看看C++中對類似C的函數(shù)是怎樣編譯的。
作為一種面向?qū)ο蟮恼Z言，C++支持函數(shù)重載，而過程式語言C則不支持。函數(shù)被C++編譯后在符號庫中的名字與C語言的不同。例如，假設某個函數(shù)的原型為：
void foo( int x, int y );
該函數(shù)被C編譯器編譯后在符號庫中的名字為_foo，而C++編譯器則會產(chǎn)生像_foo_int_int之類的名字（不同的編譯器可能生成的名字不同，但是都采用了相同的機制，生成的新名字稱為“mangled name”）。_foo_int_int這樣的名字包含了函數(shù)名、函數(shù)參數(shù)數(shù)量及類型信息，C++就是靠這種機制來實現(xiàn)函數(shù)重載的。例如，在C++中，函數(shù)void foo( int x, int y )與void foo( int x, float y )編譯生成的符號是不相同的，后者為_foo_int_float。
同樣地，C++中的變量除支持局部變量外，還支持類成員變量和全局變量。用戶所編寫程序的類成員變量可能與全局變量同名，我們以"."來區(qū)分。而本質(zhì)上，編譯器在進行編譯時，與函數(shù)的處理相似，也為類中的變量取了一個獨一無二的名字，這個名字與用戶程序中同名的全局變量名字不同。
未加extern "C"聲明時的連接方式
假設在C++中，模塊A的頭文件如下：
// 模塊A頭文件 moduleA.h
ifndef MODULE_A_H
define MODULE_A_H
int foo( int x, int y );
endif
在模塊B中引用該函數(shù)：
// 模塊B實現(xiàn)文件 moduleB.cpp
＃i nclude "moduleA.h"
foo(2,3);
實際上，在連接階段，連接器會從模塊A生成的目標文件moduleA.obj中尋找_foo_int_int這樣的符號！
加extern "C"聲明后的編譯和連接方式
加extern "C"聲明后，模塊A的頭文件變?yōu)椋?br>
// 模塊A頭文件 moduleA.h
ifndef MODULE_A_H
define MODULE_A_H
extern "C" int foo( int x, int y);
endif
在模塊B的實現(xiàn)文件中仍然調(diào)用foo( 2,3 )，其結(jié)果是：
（1）模塊A編譯生成foo的目標代碼時，沒有對其名字進行特殊處理，采用了C語言的方式；
（2）連接器在為模塊B的目標代碼尋找foo(2,3)調(diào)用時，尋找的是未經(jīng)修改的符號名_foo。
如果在模塊A中函數(shù)聲明了foo為extern "C"類型，而模塊B中包含的是extern int foo( int x, int y ) ，則模塊B找不到模塊A中的函數(shù)；反之亦然。
所以，可以用一句話概括extern “C”這個聲明的真實目的（任何語言中的任何語法特性的誕生都不是隨意而為的，來源于真實世界的需求驅(qū)動。我們在思考問題時，不能只停留在這個語言是怎么做的，還要問一問它為什么要這么做，動機是什么，這樣我們可以更深入地理解許多問題）：
實現(xiàn)C++與C及其它語言的混合編程。
明白了C++中extern"C"的設立動機，我們下面來具體分析extern "C"通常的使用技巧。
4.extern "C"的慣用法
（1）在C++中引用C語言中的函數(shù)和變量，在包含C語言頭文件（假設為cExample.h）時，需進行下列處理：
extern "C"
{
＃i nclude "cExample.h"
}
而在C語言的頭文件中，對其外部函數(shù)只能指定為extern類型，C語言中不支持extern "C"聲明，在.c文件中包含了extern "C"時會出現(xiàn)編譯語法錯誤。
筆者編寫的C++引用C函數(shù)例子工程中包含的三個文件的源代碼如下：
ifndef C_EXAMPLE_H
define C_EXAMPLE_H
extern int add(int x,int y);
endif
＃i nclude "cExample.h"
int add( int x, int y )
{
return x + y;
}
// c++實現(xiàn)文件，調(diào)用add：cppFile.cpp
extern "C"
{
＃i nclude "cExample.h"
}
int main(int argc, char* argv[])
{
add(2,3);
return 0;
}
如果C++調(diào)用一個C語言編寫的.DLL時，當包括.DLL的頭文件或聲明接口函數(shù)時，應加extern "C" {}。
（2）在C中引用C++語言中的函數(shù)和變量時，C++的頭文件需添加extern "C"，但是在C語言中不能直接引用聲明了extern "C"的該頭文件，應該僅將C文件中將C++中定義的extern "C"函數(shù)聲明為extern類型。
筆者編寫的C引用C++函數(shù)例子工程中包含的三個文件的源代碼如下：
//C++頭文件 cppExample.h
ifndef CPP_EXAMPLE_H
define CPP_EXAMPLE_H
extern "C" int add( int x, int y);
endif
//C++實現(xiàn)文件 cppExample.cpp
＃i nclude "cppExample.h"
int add( int x, int y )
{
return x + y;
}
extern int add( int x, int y );
int main( int argc, char* argv[] )
{
add( 2, 3 );
return 0;
}
