為什麼C 的庫函式的定義會這麼複雜?

時間 2021-05-30 11:06:03

1樓:

如果是VS的話,你應該可以在安裝目錄裡找到原始碼。

例如C:\Program Files (x86)\Windows Kits\10\Source\10.0.15063.0\ucrt\convert\_ctype.cpp

2樓:sin1080

這些都是M$的dll相關擴充套件搞出來的私貨,本來在C標準裡就是 int isblank(int),其他實現(比如glibc)也不會帶這些玩意。

你如果不寫windows程式也不寫準備跨平台(且要不通過cygwin直接上windows)的DLL庫,一般不用管M$的__declspec相關的東西,寫了反倒很影響可讀性。相反,如果你寫的library project準備上MSVC,你就應該準備好__declspec相關的巨集。總之扯上MSVC事情就會變煩就是了。

另外,如果你是初學者,想學C或者C++的標準,那麼你不要直接去看某個實現(比如MSVC的c標準庫或者glibc),那只是一種實現。當然直接看標準效率太低。這裡推薦 cppreference.

com 。

3樓:邱昊宇

不,C++ 的 裡,isblank 的宣告是這樣的:

namespace

std題目中的

_Check_return_

_ACRTIMP

int__cdecl

isblank

(_In_

int_C

);只是 MSVC 某個版本的實現。

只要和標準不衝突,實現可以新增自己的東西,或者在任何時候去掉自己新增的這些東西。它們都是實現細節而已。所以建議不要通過看標頭檔案來學習、分析,好好看文件吧,就算是看 MSDN 也行。

另外,C++ 為了盡可能相容 C,C 語言標準庫的函式都是能不改就不改。題目中給出的實現在原型上就有幾個問題:

bool 是 C99 才有的東西(還得 include 了 stdbool.h 才能用),所以 C 語言不可能用當時還不存在的 bool 作為返回值型別,所以 C++ 也選擇保留 int 返回值

C 語言 is 系列函式因為需要處理 EOF,而 EOF 與任何有效的 unsigned char 值都不同(通常是 -1),所以不能使用 char 系列型別,而是用 int 型。

4樓:Zhaoyang

我看過 Windows 原始碼裡一些標頭檔案,可以明確告訴你,工程裡有過之而無不及。

_Check_return_ 和 _In_ 這兩個巨集屬於 SAL(https://

),可以幫助編譯器在編譯期發現下標越界、空指標訪問之類的問題。

__cdecl 這個關鍵字是 VC++ 預設的呼叫約定(https://

),因為是預設的所以常常不寫,但當有多種呼叫約定混在一起的時候就很必要了。

_ACRTIMP 這個巨集可以顧名思義,你這個庫函式的實現在 CRT 裡,取決於你的編譯姿勢,可能在編譯時鏈結進來的某個 lib 裡,也可能在執行時 C:\Windows\System32\ 下面的某個 dll 裡。

為什麼函式極限的定義會這麼複雜?

asdlittle 這個問題和數學史有關,尤其是第二次數學危機。如果你了解這段歷史,就會知道寫下這個 定義的維爾斯特拉斯有多麼偉大。古希臘的數學迴避無窮小量的說法,他們採用的是與戴德金分割定理等價的歐多克索斯比例理論來處理有關極限 無窮小和不可公約量的問題。這不是一套簡便易學的系統,你可以看看古希臘...

函式的內積為什麼要這麼定義?

虛實道長 我想題主的困惑應該是求和完了就完了,幹嘛還要積分。也就是為何還要乘以dx。其實這就是 連續 的詭異之處。如果只是做離散分割,是可以只求乙個sum。問題在於,離散分割了的,在某個點的f xi g xi 和下個點之間,理論上還有 無窮多 點!所以在連續的情況下,問題發生了難以理解的改變,f x...

Linux 中如何快速檢視 C 庫函式的標頭檔案以及相應的函式資訊?

蒲公英 自從看了 Unix Linux程式設計實踐教程 五星推薦這本書 檢視標頭檔案和函式資訊非常方便。man k keyword grep name 查詢乙個man手冊中的簡短說明包含keyword的函式,name為函式名的關鍵字 可以不加管道 如man k timer grep set 查詢乙個...