一点感悟，不管是作人仍是写代码不能太死板了

不去继续深究模板元编程了，本身常常犯这毛病，好高骛远没有脚踏实地，研究些高手有闲情时去研究的东西，反却是本身的正业都没顾着。即便能跟高手谈笑风生，本身其实连菜鸟都不如。

打个比方，小学时候有附加题的数学考试，即便附加题能作满分，前面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每每过分纠结于底层而不是代码逻辑。

他们说得确实没错，凡事有个度，不能太死板不懂变通。