天天看點

【UIKit】-1- UIKitDefines.h - 跨平台,包容 C 庫

//  UIKit.h  之1    UIKitDefines.h

#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

 我的總結

主要是為了跨平台使用代碼  extern “C”,就是為了支援C的庫。蘋果 api 中用的比較多。

類似 UIKIT_EXTERN,對應還有FOUNDATION_EXTERN

#if defined(__cplusplus)

#define FOUNDATION_EXTERNextern "C"

#else

#define FOUNDATION_EXTERNextern

#endif

部分使用,不是很懂的樣子。

UIKIT_EXTERNNSString *const UIDeviceOrientationDidChangeNotification; // 裝置旋轉

UIKIT_EXTERNNSString *const UIDeviceBatteryStateDidChangeNotification;  // 電池狀态

UIKIT_EXTERNNSString *const UIDeviceBatteryLevelDidChangeNotification;  // 電池電量

UIKIT_EXTERNNSString *const UIDeviceProximityStateDidChangeNotification;  // 近距離傳感器

1、UIKitt提供中幾個圖像上下文(Graphics contex)的函數,此處忽略pdf相關的處理

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);

各種解釋:以下轉載

一般用于将C++代碼以标準C形式輸出(即以C的形式被調用),這是因為C++雖然常被認為是C的超集,但是C++的編譯器還是與C的編譯器不同的。C中調用C++中的代碼這樣定義會是安全的。

一般的考慮跨平台使用方法如下:

#ifdefined(__cplusplus)||defined(c_plusplus) //跨平台定義方法

extern "C"{

#endif

//... 正常的聲明段

#ifdefined(__cplusplus)||defined(c_plusplus)

}

#endif

簡單的用在windows下可以如下定義:

#ifdef  __cplusplus

extern "C"{

//... 正常的聲明段

}

#endif

某一網文:

#ifdef__cplusplus是什麼意思?

時常在cpp的代碼之中看到這樣的代碼:

#ifdef__cplusplus

extern"C"{

#endif

//一段代碼

#ifdef__cplusplus

}

#endif

這樣的代碼到底是什麼意思呢?

首先,__cplusplus是cpp中的自定義宏,那麼定義了這個宏的話表示這是一段cpp的代碼,也就是說,上面的代碼的含義是:

    如果這是一段cpp的代碼,那麼加入extern"C"{和}處理其中的代碼。

    要明白為何使用extern"C",還得從cpp中對函數的重載處理開始說起。在c++中,為了支援重載機制,在編譯生成的彙編碼中,要對函數的名字進行一些處理,加入比如函數的傳回類型等等.而在C中,隻是簡單的函數名字而已,不會加入其他的資訊.也就是說:C++和C對産生的函數名字的處理是不一樣的.

比如下面的一段簡單的函數,我們看看加入和不加入extern"C"産生的彙編代碼都有哪

些變化:

intf(void)

{

return1;

}

在加入extern"C"的時候産生的彙編代碼是:

.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指令産生的,所有的地方都是一樣的,唯獨是産生的

函數名,一個是_f,一個是__Z1fv。

明白了加入與不加入extern"C"之後對函數名稱産生的影響,我們繼續我們的讨論:為什

麼需要使用extern"C"呢?C++之父在設計C++之時,考慮到當時已經存在了大量的C代碼,

為了支援原來的C代碼和已經寫好C庫,需要在C++中盡可能的支援C,而extern"C"就是

其中的一個政策。

試想這樣的情況:一個庫檔案已經用C寫好了而且運作得很良好,這個時候我們需要使

用這個庫檔案,但是我們需要使用C++來寫這個新的代碼。如果這個代碼使用的是C++的

方式連結這個C庫檔案的話,那麼就會出現連結錯誤.我們來看一段代碼:首先,我們使用C

的處理方式來寫一個函數,也就是說假設這個函數當時是用C寫成的:

//f1.c

extern"C"

{

voidf1()

{

return;

}

}

編譯指令是:gcc-cf1.c-of1.o産生了一個叫f1.o的庫檔案。再寫一段代碼調用這個f1

函數:

//test.cxx

//這個extern表示f1函數在别的地方定義,這樣可以通過

//編譯,但是連結的時候還是需要

//連結上原來的庫檔案.

externvoidf1();

intmain()

{

f1();

return0;

}

通過gcc-ctest.cxx-otest.o産生一個叫test.o的檔案。然後,我們使用gcctest.of1.o來

連結兩個檔案,可是出錯了,錯誤的提示是:

test.o(.text+0x1f):test.cxx:undefinereferenceto'f1()'

也就是說,在編譯test.cxx的時候編譯器是使用C++的方式來處理f1()函數的,但是實

際上連結的庫檔案卻是用C的方式來處理函數的,是以就會出現連結過不去的錯誤:因為鍊

接器找不到函數。

是以,為了在C++代碼中調用用C寫成的庫檔案,就需要用extern"C"來告訴編譯器:

這是一個用C寫成的庫檔案,請用C的方式來連結它們。

比如,現在我們有了一個C庫檔案,它的頭檔案是f.h,産生的lib檔案是f.lib,那麼我

們如果要在C++中使用這個庫檔案,我們需要這樣寫:

extern"C"

{

#include"f.h"

}

回到上面的問題,如果要改正連結錯誤,我們需要這樣子改寫test.cxx:

extern"C"

{

externvoidf1();

}

intmain()

{

f1();

return0;

}

重新編譯并且連結就可以過去了.

總結

C和C++對函數的處理方式是不同的.extern"C"是使C++能夠調用C寫作的庫檔案的一

個手段,如果要對編譯器提示使用C的方式來處理函數的話,那麼就要使用extern"C"來說

明。 

另一篇文章:

#ifdef__cplusplus

#ifdef__cplusplus倒底是什麼意思?

時常在cpp的代碼之中看到這樣的代碼:

#ifdef__cplusplus

extern "C" {

#endif

//一段代碼

#ifdef__cplusplus

}

#endif

  這樣的代碼到底是什麼意思呢?首先,__cplusplus是cpp中的自定義宏,那麼定義了這個宏的話表示這是一段cpp的代碼,也就是說,上面的代碼的含義是:如果這是一段cpp的代碼,那麼加入extern "C"{和}處理其中的代碼。

  要明白為何使用extern "C",還得從cpp中對函數的重載處理開始說起。在c++中,為了支援重載機制,在編譯生成的彙編碼中,要對函數的名字進行一些處理,加入比如函數的傳回類型等等.而在C中,隻是簡單的函數名字而已,不會加入其他的資訊.也就是說:C++和C對産生的函數名字的處理是不一樣的.

  比如下面的一段簡單的函數,我們看看加入和不加入extern"C"産生的彙編代碼都有哪些變化:

int f(void)

{

return 1;

}

  在加入extern "C"的時候産生的彙編代碼是:

.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指令産生的,所有的地方都是一樣的,唯獨是産生的函數名,一個是_f,一個是__Z1fv。

  明白了加入與不加入extern "C"之後對函數名稱産生的影響,我們繼續我們的讨論:為什麼需要使用extern "C"呢?C++之父在設計C++之時,考慮到當時已經存在了大量的C代碼,為了支援原來的C代碼和已經寫好C庫,需要在C++中盡可能的支援C,而extern"C"就是其中的一個政策。

  試想這樣的情況:一個庫檔案已經用C寫好了而且運作得很良好,這個時候我們需要使用這個庫檔案,但是我們需要使用C++來寫這個新的代碼。如果這個代碼使用的是C++的方式連結這個C庫檔案的話,那麼就會出現連結錯誤.我們來看一段代碼:首先,我們使用C的處理方式來寫一個函數,也就是說假設這個函數當時是用C寫成的:

//f1.c

extern "C"

{

void f1()

{

return;

}

}

  編譯指令是:gcc -c f1.c -o f1.o産生了一個叫f1.o的庫檔案。再寫一段代碼調用這個f1函數:

// test.cxx

//這個extern表示f1函數在别的地方定義,這樣可以通過

//編譯,但是連結的時候還是需要

//連結上原來的庫檔案.

extern void f1();

int main()

{

f1();

return 0;

}

  通過gcc -c test.cxx -o test.o産生一個叫test.o的檔案。然後,我們使用gcc test.o f1.o來連結兩個檔案,可是出錯了,錯誤的提示是:

test.o(.text + 0x1f):test.cxx: undefinereference to 'f1()'

  也就是說,在編譯test.cxx的時候編譯器是使用C++的方式來處理f1()函數的,但是實際上連結的庫檔案卻是用C的方式來處理函數的,是以就會出現連結過不去的錯誤:因為連結器找不到函數。

  是以,為了在C++代碼中調用用C寫成的庫檔案,就需要用extern "C"來告訴編譯器:這是一個用C寫成的庫檔案,請用C的方式來連結它們。

  比如,現在我們有了一個C庫檔案,它的頭檔案是f.h,産生的lib檔案是f.lib,那麼我們如果要在C++中使用這個庫檔案,我們需要這樣寫:

extern "C"

{

#include "f.h"

}

  回到上面的問題,如果要改正連結錯誤,我們需要這樣子改寫test.cxx:

extern "C"

{

extern void f1();

}

int main()

{

f1();

return 0;

}

  重新編譯并且連結就可以過去了.

  總結

C和C++對函數的處理方式是不同的.extern "C"是使C++能夠調用C寫作的庫檔案的一個手段,如果要對編譯器提示使用C的方式來處理函數的話,那麼就要使用extern "C"來說明。

1.引言

C++語言的建立初衷是“a better C”,但是這并不意味着C++中類似C語言的全局變量和函數所采用的編譯和連接配接方式與C語言完全相同。作為一種欲與C相容的語言,C++保留了一部分過程式語言的特點(被世人稱為“不徹底地面向對象”),因而它可以定義不屬于任何類的全局變量和函數。但是,C++畢竟是一種面向對象的程式設計語言,為了支援函數的重載,C++對全局函數的處理方式與C有明顯的不同。

2.從标準頭檔案說起

某企業曾經給出如下的一道面試題:

面試題

為什麼标準頭檔案都有類似以下的結構?

#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"限定的函數或變量是extern類型的;

extern是C/C++語言中表明函數和全局變量作用範圍(可見性)的關鍵字,該關鍵字告訴編譯器,其聲明的函數和變量可以在本子產品或其它子產品中使用。記住,下列語句:

extern int a;

僅僅是一個變量的聲明,其并不是在定義變量a,并未為a配置設定記憶體空間。變量a在所有子產品中作為一種全局變量隻能被定義一次,否則會出現連接配接錯誤。

通常,在子產品的頭檔案中對本子產品提供給其它子產品引用的函數和全局變量以關鍵字extern聲明。例如,如果子產品B欲引用該子產品A中定義的全局變量和函數時隻需包含子產品A的頭檔案即可。這樣,子產品B中調用子產品A中的函數時,在編譯階段,子產品B雖然找不到該函數,但是并不會報錯;它會在連接配接階段中從子產品 A編譯生成的目标代碼中找到此函數。

與extern對應的關鍵字是static,被它修飾的全局變量和函數隻能在本子產品中使用。是以,一個函數或變量隻可能被本子產品使用時,其不可能被extern “C”修飾。

(2)被extern "C"修飾的變量和函數是按照C語言方式編譯和連接配接的;

未加extern “C”聲明時的編譯方式

首先看看C++中對類似C的函數是怎樣編譯的。

作為一種面向對象的語言,C++支援函數重載,而過程式語言C則不支援。函數被C++編譯後在符号庫中的名字與C語言的不同。例如,假設某個函數的原型為:

void foo( int x, int y );

該函數被C編譯器編譯後在符号庫中的名字為_foo,而C++編譯器則會産生像_foo_int_int之類的名字(不同的編譯器可能生成的名字不同,但是都采用了相同的機制,生成的新名字稱為“mangled name”)。_foo_int_int這樣的名字包含了函數名、函數參數數量及類型資訊,C++就是靠這種機制來實作函數重載的。例如,在C++中,函數void foo( int x, int y )與void foo( int x, float y )編譯生成的符号是不相同的,後者為_foo_int_float。

同樣地,C++中的變量除支援局部變量外,還支援類成員變量和全局變量。使用者所編寫程式的類成員變量可能與全局變量同名,我們以"."來區分。而本質上,編譯器在進行編譯時,與函數的處理相似,也為類中的變量取了一個獨一無二的名字,這個名字與使用者程式中同名的全局變量名字不同。

未加extern "C"聲明時的連接配接方式

假設在C++中,子產品A的頭檔案如下:

// 子產品A頭檔案 moduleA.h

#ifndef MODULE_A_H

#define MODULE_A_H

int foo( int x, int y );

#endif

在子產品B中引用該函數:

// 子產品B實作檔案 moduleB.cpp

#i nclude "moduleA.h"

foo(2,3);

實際上,在連接配接階段,連接配接器會從子產品A生成的目标檔案moduleA.obj中尋找_foo_int_int這樣的符号!

加extern "C"聲明後的編譯和連接配接方式

加extern "C"聲明後,子產品A的頭檔案變為:

// 子產品A頭檔案 moduleA.h

#ifndef MODULE_A_H

#define MODULE_A_H

extern "C" int foo( int x, int y);

#endif

在子產品B的實作檔案中仍然調用foo( 2,3 ),其結果是:

(1)子產品A編譯生成foo的目标代碼時,沒有對其名字進行特殊處理,采用了C語言的方式;

(2)連接配接器在為子產品B的目标代碼尋找foo(2,3)調用時,尋找的是未經修改的符号名_foo。

如果在子產品A中函數聲明了foo為extern "C"類型,而子產品B中包含的是extern int foo( int x, int y ) ,則子產品B找不到子產品A中的函數;反之亦然。

是以,可以用一句話概括extern “C”這個聲明的真實目的(任何語言中的任何文法特性的誕生都不是随意而為的,來源于真實世界的需求驅動。我們在思考問題時,不能隻停留在這個語言是怎麼做的,還要問一問它為什麼要這麼做,動機是什麼,這樣我們可以更深入地了解許多問題):

實作C++與C及其它語言的混合程式設計。

明白了C++中extern"C"的設立動機,我們下面來具體分析extern "C"通常的使用技巧。

4.extern "C"的慣用法

(1)在C++中引用C語言中的函數和變量,在包含C語言頭檔案(假設為cExample.h)時,需進行下列處理:

extern "C"

{

#i nclude "cExample.h"

}

而在C語言的頭檔案中,對其外部函數隻能指定為extern類型,C語言中不支援extern "C"聲明,在.c檔案中包含了extern "C"時會出現編譯文法錯誤。

筆者編寫的C++引用C函數例子工程中包含的三個檔案的源代碼如下:

#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++實作檔案,調用add:cppFile.cpp

extern "C"

{

#i nclude "cExample.h"

}

int main(int argc, char* argv[])

{

add(2,3);

return 0;

}

如果C++調用一個C語言編寫的.DLL時,當包括.DLL的頭檔案或聲明接口函數時,應加extern "C" {}。

(2)在C中引用C++語言中的函數和變量時,C++的頭檔案需添加extern "C",但是在C語言中不能直接引用聲明了extern "C"的該頭檔案,應該僅将C檔案中将C++中定義的extern "C"函數聲明為extern類型。

筆者編寫的C引用C++函數例子工程中包含的三個檔案的源代碼如下:

//C++頭檔案 cppExample.h

#ifndef CPP_EXAMPLE_H

#define CPP_EXAMPLE_H

extern "C" int add( int x, int y);

#endif

//C++實作檔案 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;

}