脚本宝典收集整理的这篇文章主要介绍了

LtRay的艰难重构(一)

脚本宝典小编觉得挺不错的,现在分享给大家,也给大家做个参考,希望能帮助你少写一行代码,多一份安全和惬意。

从去年九月份开始,我就在着手实现一个光线跟踪器:LtRay。刚开始进展很快,差不多三天的时间,光线跟踪器的雏形就已经具备了,能够对一些简单的图元比如球体、平面等进行渲染,并且还具有反射、阴影效果。但是越到后面,开发的进度就越来越慢了,近两个月几乎就是做些填补工作。现在每改一个地方,几乎就得花费一两天的时间来修复相关的代码。前不久刚定下v0.1.7版本,渲染的效果如下:

LtRay

而这跟我两个月前的版本相比,几乎就只是把光线跟踪的核心分离出来,另外把场景文件的格式从json改成了toml。每遇到一个问题,我都在纠结到底该哪一种方式来解决,实际上,这种犹豫耗费了大量的时间。摆在我面前的方法仿佛有无数种,但就是没法确定哪一种是最好的,结果就是反复修改来修改去,比如我遇到的有这些坑:

第三方库

针对于第三方库这个问题,其实一开始我是拒绝使用的。我使用的是CMake构建工程的方式,因为大量使用第三方库的话会导致环境配置麻烦,CMakeLists编写复杂,为此花费了很多时间。而很多库其实只用到了功能的一小部分,完全可以自己实现,比如PBM和PGM图片的读写,这个很简单,我就直接自己写了。到后面,需要用到json来定义场景文件的时候,我是依然选择了自己写json解析器。这真是已经费力不讨好的事情,我花了很多时间编写完善json解析器,到后面发现用json定义场景文件并不是很方便,转而又使用toml。前后一折腾,那些工作就相当于白干了。

工程构建

我曾算是Linux和开源精神的簇拥,就连一个很小的程序都要写个CMakeLists,时时刻刻注意着跨平台。但现在让我去写代码,我会毫不犹豫选择Windows和Visual Studio,因为Visual Studio实在是太方便了,特别是结合NuGet来管理第三方库,简直畅快无比,再也不用手动去配置和管理第三方库了。所以我现在是大胆使用第三方库,只要这个库是比较稳定的有人在维护的就好,比如现在LtRay中就用了glfw来显示窗口、FreeImage来加载图片、cpptoml来解析toml文件。效率就是生产力,在生产力面前,那些Linux情怀就免谈了吧。

规范

代码规范很容易解决,难的就是C++多范式带来的选择困难。同一个问题有无数种解决方法,而我往往是实现了一种,后来又发现不怎么好,又回过头来修改,就这样反反复复不知道修改了多少次。期初代码量很少还好,到现在几乎全是改代码了。

该不该用getter,setter?

我起初是恪守“类应该对外部只应该暴露接口函数”这一规则的,但是到后面发现这真是太繁琐了,可读性和可维护性都大大降低了。比如Point、Vector、Color这些类,只有三四个成员变量,而且这些变量是不受约束的,本来一个很简单的struct Color{float r,g,b};结果用getter、setter包装起来后,代码真是变得啰嗦无比。我个人觉得对于简单类使用这种getter、setter方式无异于掩耳盗铃。

该不该用全部改用智能指针?

C++11中的智能指针确实很方便,但其实质还是个资源管理的工具,如果把所有的指针都用智能指针代替,那就会使得资源的生命周期难以掌控。最好的方法就是只在需要自动回收资源的地方使用智能指针,对于那些只是暂时借用对象的指针的函数,直接传递指针就好了。

C++入门并不难,但这些寻求“最佳实践”的过程可能会永无止境。

总结

以上是脚本宝典为你收集整理的

LtRay的艰难重构(一)

全部内容,希望文章能够帮你解决

LtRay的艰难重构(一)

所遇到的程序开发问题,欢迎加入QQ群277859234一起讨论学习。如果觉得脚本宝典网站内容还不错,欢迎将脚本宝典网站推荐给程序员好友。 本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。如您有任何意见或建议可联系处理。小编QQ:384754419,请注明来意。

80%的人都看过