不去继续深究模板元编程了，自己经常犯这毛病，好高骛远没有脚踏实地，研究些高手有闲情时去研究的东西，反倒是自己的正业都没顾着。即使能跟高手谈笑风生，自己其实连菜鸟都不如。
打个比方，小学时候有附加题的数学考试，即使附加题能做满分，前面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往往过度纠结于底层而不是代码逻辑。
他们说得确实没错，凡事有个度，不能太死板不懂变通。