一點感悟，不管是作人仍是寫代碼不能太死板了

不去繼續深究模板元編程了，本身常常犯這毛病，好高騖遠沒有腳踏實地，研究些高手有閒情時去研究的東西，反卻是本身的正業都沒顧着。即便能跟高手談笑風生，本身其實連菜鳥都不如。

打個比方，小學時候有附加題的數學考試，即便附加題能作滿分，前面100分不及格也是枉然。雖然前面都及不了格確定附加題也作不會，可是編程的學習不是小學數學那麼單一化的，而是多元化的，有不少方向，不該該沉迷於錯誤的方向。

回到正業，本身封裝個讀取BMP圖像的類，能同時知足8位和24位的BMP圖像讀取。

重複造輪子確實不必，原本也下了個講OpenCV3.0的電子書，可是能夠算是訓練一下面向對象程序設計的能力。

因此此次連OpenCV的IplImage都沒用了，由於若是是本身實現的話，讀取、保存BMP圖像，而且爲之設計好用的接口是主要的難點，在此接口之上實現一些基本圖像處理算法相對容易多了。

而後在讀取調色板時出了問題，只能讀取前25個顏色，後面的全是空的。

試着先把後面的數據讀完，發現調試的時候速度有點慢。

自從系統地學了C++後，結合之前網上這裏看看那裏瞧瞧的帖子，「不要寫C風格的C++」如同永恆真理同樣刻在了我心裏深處。

因此能用智能指針的時候就用智能指針，能用vector取代指針構造動態數組就用vector代替。

——因而我在Bitmap類的內部用std::vector<unsigned char>來保存圖像像素數據，期初還用std::vector<std::shared_ptr<unsigned char>>，後來拍腦門一想，unsigned char比起指針，佔用位數還小些。

 

另外，因爲幾乎公認iostream又是C++設計的敗筆，因而在C++ I/O流仍是C風格I/O上糾結了好久，還看了很多帖子，最後在stackoverflow的討論上看到告終果。

——有人這麼說的：在正式過程當中這兩個都不多用，通常是有專門的I/O庫，或者基於系統底層API封裝。（PS：跟陳碩的那篇分析結論一致）

是啊，平時寫娛樂程序還糾結這麼多幹啥，並且他們着眼於大型過程的日誌文檔I/O，我不過是讀個圖像，到時候真要應用也會用專門的讀取庫之類。

寫娛樂程序的目的是爲了練手，固然，效率也是要考慮的，可是這就慢慢偏離了最初的方向。

不管是C++ I/O流仍是C風格I/O，讀取單幅圖像效率幾乎沒差，反倒影響效率的是用vector存儲數據，由於這樣就不能連續地read，Debug模式下，讀取256*256個元素都要用0.05秒，分配動態一維數組速度快了不少，只需0.01秒左右，而分配動態二維數組耗時只要0.002秒。

——像這樣，寫娛樂程序就達到了目的，可以看清楚它們在效率上的差別，這樣之後寫程序時就能夠考慮能不能捨棄一點C++風格來換取運行速度的提高。而不是死板地堅持C++風格的程序。

不過也有多是個人設計問題，畢竟若是在整個程序耗時較多的狀況下，0.05秒的時間差可能顯得並很少，這樣捨棄C++風格並不能給運行速度帶來有效的提高，關鍵仍是數據結構和算法的設計，也就是基本功。與其花時間過分糾結語言，還不如好好練下這基本功。

瞭解底層也沒錯，但也有個度，之前也看過有人說新手不實際作項目很容易迷失於底層，也看過其餘語言使用者說C++er每每過分糾結於底層而不是代碼邏輯。

他們說得確實沒錯，凡事有個度，不能太死板不懂變通。