特定於API的類型定義（如GLsizei GLint GLvoid）的用途是什麼？

api特定類型定義（如GLsizei GLint GLvoid）的用途是什麼？特定於API的類型定義（如GLsizei GLint GLvoid）的用途是什麼？

我在c和C++代碼中隨處可見。基本類型通常使用庫前綴/後綴。這背後的理由是什麼？這是好的做法嗎？我的程序應該自己做類似的事情嗎？

乍一看，它似乎使代碼可讀性稍差。你必須立即將GLint翻譯成int，這是一個簡單的例子。

像UINT這樣的事情對我來說更重要，至少這是將unsigned int縮短爲四個。

來源

2010-11-21 Lockyer

這不是關於縮短名稱，而是關於可移植性。不同的平臺需要以不同的方式輸入這些東西。

在標準C中，long可能是32位或64位，具體取決於您的編譯器/目標，因此不能安全地假定爲特定大小。因此，圖書館作者將根據目標平臺的知識鍵入自己的類型，保證一定的大小。

E.g.

#ifdef _WIN32 
typedef __int64 INT64; // long will not be 64 bit on Windows/VC. 
#elif __GNU_C__ 
typedef long INT64; // gcc typically uses 64 bit longs. 
#elif // ... other platforms ... 
... 
#endif

如果編譯器在將來的版本中更改類型屬性，則可以在一個位置編輯類型。

在過去，你也有地方int可能在大小16個或32位的一個典型案例，所以你不能簡單地使用原始int類型的代碼，你需要一個尺度的DWORD爭論。

因此，爲什麼你有像LPARAM和WPARAM東西。

它也被用作抽象的一種形式。這就是爲什麼你看到像

typedef int Handle;

的typedef因爲儘管它是一個int現在，庫作者保留以後改變它在軌道下到別的能力，說void *，或任何其他類型的，他們認爲有必要的。

但客戶端代碼並不需要知道它是否是int，因爲這正是它當前的情況。所有客戶需要知道的是將它傳遞給接受Handle類型的函數。

Typedefs還允許在編譯時進行配置。例如。一些圖書館可能有一個Real類型的實數。它可以在諸如

#ifdef USE_DOUBLE_PREC 
typedef double Real; 
#else 
typedef float Real; 
#endif

而且庫的用戶可以選擇設置/DUSE_DOUBLE_PREC編譯獲得雙精度浮點數的支持時的方式來定義，但重要的是，沒有庫代碼需要爲這個改變工作，因爲它已被抽象化。

來源

2010-11-21 13:50:49

它提供了在一個地方更改typedef的功能，而不是在代碼庫中搜索和替換整個代碼庫，如果需要以某種方式更改基礎類型。但是，我也發現它比任何東西都更「噪音」，而且在實際生活中很少見到它。

我見過一個體面的使用唯一的例子是浮動如果你碰巧在遊戲中工作，並可能需要將遊戲移植到Nintendo DS，因爲DS原生使用定點數。在這種情況下，你有一個特殊的浮點類型定義，這樣它就可以在大多數平臺上浮點類型化，也可以在DS上定義一個特殊的定點類。

來源

2010-11-21 08:51:15

定點和浮點的共同點很少，任何使用定點的代碼都可能想要並且應該在任何地方都使用定點... – 2010-11-21 13:00:52

您會驚訝地發現，一類。我做過合同工作的一家公司擁有的BLAH_FLOAT（其中「BLAH」是其公司首字母縮寫）的引擎，因此DS和非DS版本的代碼可以和平共處。 – 2010-11-21 19:08:15

我的意思並不是在實現中，而是在語義上。例如，如果你的值是座標，它們應該是固定點或浮點數，並加上**巨大的**偏差。否則，精度會隨着位置而變化，遠遠高於原點，這意味着行爲不是平移不變的。 – 2011-01-24 17:21:53

在大多數情況下，當一個庫定義與在標準超越類似命名的類型沒有保證屬性的基本類型（認爲INT，GLint，gint，LPSTR，u32，u_int，等），其目的可以是：

以「品牌」你的代碼，有很多嚴格的依賴性庫，因此它是一個痛苦的重用代碼沒有圖書館，或
無知的C標準庫的需求提供相應的類型。

根據我最喜歡的原則之一「永遠不會因爲惡意可以充分解釋什麼是惡意」，你可能會去＃2，但這真的取決於你。

個人編碼時這樣的API，我在他們的地方扔出去的庫特定的類型並使用正確的自然類型（int，char *，uint32_t等）。然後，很容易調整我的代碼，以便在不需要庫的情況下使用，而且對於不熟悉庫的人員來說代碼更易讀。

來源

2010-11-21 12:54:55

用「C標準」慢下來，OpenGL不僅適用於C，而且與C（或任何其他編程語言）無關。 :)它不是一個「庫」，它是一個API。 – Kos 2010-11-21 15:50:31

沒有獨立於語言的API。當然你可以嘗試爲多種語言製作類似外觀的API版本，並取得不同的成功。（讓OpenGL API在Brainf * ck中看起來相同。）當以特定語言實例化API時，您需要遵循該語言的約定，特別是在類型方面。許多語言甚至沒有類型，並試圖對它們施加一些荒謬的想法，而不是使用它們原生的表示整數的方式，這會讓語言用戶興奮起來。 C值得同樣的尊重。 – 2010-11-21 16:34:32

@Kos：這是一個標準，有一個規範。規範是以與語言無關的方式編寫的。 @R：平臺OpenGL標題是用C89編寫的。 C89沒有對具有精確大小的整型類型的typedef，比如int32_t，所以他們必須定義它們自己的。另外，你的1.）是錯誤的。爲什麼有人會故意這樣做？通常，當你看到奇怪的東西時，你可以經常把它歸咎於遺留代碼*，而不是惡意或愚蠢。 – 2010-11-21 17:07:57

特定於API的類型定義（如GLsizei GLint GLvoid）的用途是什麼？

回答

相關問題