[ C++ ] 對整數型別賦值
基礎物件的型別決定了物件能夠存放的值。
所以如果將超出某型別允許範圍的值指派給一個該型別的物件。
ex. 32bit 的作業系統 中的 int 可容納 2³² 的數值範圍 = -2,147,483,648 ~ 2,147,483,647。
Q: 所以如果將 5,000,000,000 丟到 int 中會發生什麼事 ？
在遊戲專案進行一段時間後， 隨著檔案數量的增加， 往往會發現專案的編譯時間會越來越長。 而 C++ 的特性也使得原始碼檔案會隨著時間而暴漲。
那麼編譯時間的增長原因究竟有哪些？
- 1. 標頭檔 include 不必要的檔案過多， 往往是因為沒有嚴格使用 Forward Declaration 的方式， 導致專案中的源碼相依關係過高， 造成編譯時間暴增。
在《Effective C++》中的第 31 項條款，對於編譯依存關係的問題，刻下每位程式設計者都應該謹記於心的三條戒文：
1. 如果 object references 或 object pointers 可以完成任務，就不要使用 objects。
2. 如果能夠，盡量以 class 的宣告取代 class 的定義。
3. 不要在表頭檔中 #include 其他表頭檔，除非你的表頭檔不這樣就無法編譯。
好吧， 萬一真的很懶散， 隨便寫程式， 要用什麼方式來解決這個問題！？
可以使用 cppclean 這個小工具來幫助你找到 header 檔中不必要的引入。
cppclean Github
- 2. 將開源的 Cocos2dx 的 c++ 專案中的原始碼都引入專案中。
Cocos2dx 本身的 c++ 專案就蠻肥的， 有八百多個原始檔案， 光本身第一次編譯的時間就挺讓人不耐煩， 如果沒有要更改的話， 建議可以使用 Prebuild 的版本丟入專案中。
- 3. 程式碼的架構不夠扁平 。 簡單說， 改到越底層的檔案， 所有與該檔案相關的原始碼都需要重新編譯。 所謂的相關也就是程式碼有相依性。
減少元件之間的相依性， 往往是個不錯的習慣， 而架構越扁平， 帶來的是相依性的降低， 卻也讓元件的重複使用可能性降低， 這個拿捏就需要些經驗了。
One more thing.
Large Scale C++ Software Design 所介紹的 Redundant Guards 的技巧是幫助不大的。
// Somefile.h #ifndef SOMEFILE_H_ #include “SomeFile.h” #endif #ifndef SOMEOTHERFILE_H_ #include “SomeOtherFile.h” #endif
# pragma once 也是一樣的情況。
有興趣看原文的可以參考。