GTK數據類型vs基本數據類型

Question

我開始用GTK +來做一些小項目。

GLib的限定一系列數據類型，如gintgpointer等，它們只是typedef氏鹼的數據類型（gint爲int一個typedef，gpointer爲void*等）。

現在，假設我有一個函數或類不會使用GTK。我真的很想使用基礎數據類型，這樣即使我不包含GTK頭文件，我也可以在其他地方重用類/函數。另一方面，如果在代碼中混合使用gint和int，我發現它們相當難看，當它們實際上是相同的東西時。

總之，我想知道是否存在時，使用一個或另一個，或者如果一個應該只是隨意混合這些標準的做法...

Answer 1

我處理這個問題很多與工作第三方庫，他們都希望爲整數自己的類型別名，花車，多頭，空頭，字節別名來代替字符等

這是非常煩人。通常這樣做是爲了確保可移植性，但最終會爲每個庫提供自己的標準。

我發現這裏最令人不快的是從耦合的角度來看。我可能有一個通用的網格界面，應該從任何渲染問題中分離出來。然而，它的一些數據可能會直接傳遞給OpenGL函數，該函數想要假設我們通過的整數大小將匹配sizeof(GLint)。

在某些情況下，這不僅僅是美學。將GL頭文件包含在這個網格頭文件中​​可能不是合理的，因爲它可能是廣泛使用的軟件開發工具包的一部分，它不應該要求使用它的第三方插件編寫人員具有編譯時間依賴性。

可移植性是一個問題。我設法在非常大規模的傳統C代碼庫中存活了一個惡夢般的場景，其中暗示了整個代碼庫sizeof(int) == sizeof(void*)。它花了數年的時間在乾草堆中尋找針頭以將此代碼庫移植到64位。

我個人已經解決的問題是多年來開始傾向於使用普通的舊的非混淆數據類型。我也喜歡使用帶符號的整數，例如我發現過去甚至避免通過容器的基本循環中的警告，其中一些將使用int，其他unsigned int，其他size_t等來指示包含的元素的數量。至少個人而言，我發現我的維護時間減少了，只是傾向於int沒有一個很好的理由不這樣做。

要在某些平臺上嘗試減輕某些潛在的最壞情況，例如，我傾向於大量散佈圍繞代碼的斷言，使得這兩者相等：assert(sizeof(int) == sizeof(GLint));。這應該可以顯着減輕我在從32位移植到64位時所遇到的那種噩夢般的場景帶來的痛苦。它也明確表達了這些假設。

我發現這樣可以爲我的情況建立一個舒適的平衡。當然，這些都是主觀的，根據你的使用情況可以有很大的不同。但是，這是一種可能的解決方案，儘管有所有這些第三方庫，但是如果您的假設在某些平臺上停止是正確的，那麼可能會允許您越來越多地使用普通的舊的非混淆數據類型，而不會面臨最壞的情況。