您好,登錄后才能下訂單哦!
本篇內容介紹了“怎么用Pragma來廢棄API”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
想象一下這個工作場景:你在為一個項目寫一個功能庫,別人調用庫中提供的函數,后來你發現庫里的函數A是多余的。
具有完美情節的你,就是想把這個函數A廢棄掉,此時肯定是不能直接刪掉,因為你不知道別人在多少個地方調用了這個函數。
這種情況如何處理比較好呢?
這篇小短文就來聊一聊這個問題。
測試文件只有 3 個:api.h, api.c 和 main.c
api.h 和 api.c: 庫文件,編譯得到 libapi.so;
main.c:生成可執行程序,利用了上面生成的庫 libapi.so;
api.h 文件內容:聲明了 2 個函數。
api.c 文件內容:定義了 2 個函數。
編譯得到庫文件 libapi.so。編譯指令:
gcc -fPIC -shared api.c -o libapi.so
main.c 文件內容:
編譯得到可執行文件:
gcc main.c -o main -L./ -Wl,-rpath=./ -lapi
以上代碼的簡單程度,等價于 helloworld 了。
現在,你覺得 init 這個函數是多余的,想把它去掉,可以這么來修改。
api.c 文件中,把 init() 函數刪除掉。
api.h 文件內容改為如下:
關鍵代碼是這一行:
#define init() (1) API_DEPRECATED
既然 api.c 文件已經把這個函數刪除了,但是 main.c 文件中又調用了這個函數,因此以宏定義的形式提供 init 這個符號。
也就是說:
在第一個版本中,main.c 文件中的 init 是一個函數,被編譯器處理,在鏈接階段從 libapi.so 庫中找到這個函數的地址;
在第二個版本中,init 被定義成宏,在預處理階段被替換成后面的 (1) API_DEPRECATED。
(1) 是在宏替換時的表達式。因為這個函數可能被用在 if 條件判斷中,因此需要返回一個值。
API_DEPRECATED 是另一個宏定義,擴展開來后就是讓編譯器在編譯可執行程序時,打印出一段提示信息。
在編譯可執行文件時,編譯器輸出下面的這段話:
gcc main.c -o main -L./ -Wl,-rpath=./ -lapi
這樣就達到了最初的目的!也就是提示使用者:這個函數已經被廢棄了,最好別用它!
_Pragma 類似于 Microsoft 特定的 __pragma 關鍵字,只不過它是標準的一部分。它是在 C99 中為 C 引入的。對于 c + +,它是在 c + + 11 中引入的。它允許將指令放入宏定義中。
在頭文件中,為了防止被重復包含,一般有 3 種處理方式:
(1) 第一種處理方式:
#ifdef MY_API #define MY_API // 頭文件內容 #endif
(2) 第二種處理方式
#pragma once // 頭文件內容
以上這 2 種方式都可以防止同一個頭文件被重復包含,但是還是有一些區別的。
第一種方式:預處理器還是需要去搜尋文件,然后打開文件,讀取文件的內容之后,檢查 MY_API 是否已經被定義過。
第二種方式:能加快編譯速度,因為這是一種高端的機制;編譯器會自動比對文件名,而不需要在頭文件去判斷 #ifndef 和 #endif,這樣就省去了中間的搜尋、打開和讀取操作。
(3) 第三種處理方式
_Pragma("once")
這種方式與第二種方式的區別是:
#pragma :是一條預處理的指令,用來向編譯器傳達語言標準以外的一些信息,不能使用在宏中;
_Pragma :是一個操作符,屬于語言的標準,因此可以嵌套在宏中,就像上面示例中那樣;
#pragma 是編譯器的擴展,也就是說它是由編譯器來決定的,也許編譯器A支持,但是編譯器B就不一定支持了,雖然這種可能性比較小。
_Pragma 操作符是語言層面的標準,既然是標準,那么編譯器就必須要遵循標準,所以也推薦使用這種方式。
記得侯杰老師在 C++ 的視頻課程中說到:我們寫代碼,不僅僅要保證功能上的正確,而且要把代碼寫的很大氣!我感覺用 _Pragma 可能比 #ifndef 更大氣一些。
#pragma message("the #pragma way") _Pragma ("message( \"the _Pragma way\")")
上面兩行的內容輸出信息是一樣的,需要注意的是嵌套的雙引號需要用反斜線去轉義。
“怎么用Pragma來廢棄API”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。