一点感悟,无论是做人还是写代码不能太死板了

Posted Harley_Quinn

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了一点感悟,无论是做人还是写代码不能太死板了相关的知识,希望对你有一定的参考价值。

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

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

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

以上是关于一点感悟,无论是做人还是写代码不能太死板了的主要内容,如果未能解决你的问题,请参考以下文章

如何写好代码?

代码风格的一点小感悟

我的结对编程搭档——常秉玉

Noip2017 感悟

多线程累加求和

编码感悟——写出好代码