`
阿尔萨斯
  • 浏览: 4107139 次
社区版块
存档分类
最新评论

5年后的OGRE3D,与从其中SHARED_PTR谈开

 
阅读更多
<iframe align="center" marginwidth="0" marginheight="0" src="http://www.zealware.com/csdnblog336280.html" frameborder="0" width="336" scrolling="no" height="280"></iframe>

OGRE3D 引擎一向与时俱进,依靠强大开源社区的支撑,总是能很快地把比较新的图形引擎技术加入其中。几年下来,它成了一个试验最新图形技术的平台。1。2支持了d3d的MTR(multi render target)--- deferred shading. 双面STENCIL BUFFER---更快的shadow volume(en...没看到depth clipping), instance(绘制草),各种post processing 技术. FX,CG,HLSL,GLSL支持,场景管理有OCTREE,BSP,TERRAIN(QUADTREE),一整套UI(CEGUI)。 基本上,作为一个图形程序员,这几年想弄的东西,它里面基本都包含了。虽然不是每项都精,但现在这种大而全的规模,另外感叹. 只要SHADERX系列,GPU GEMS系列,GPG系列,NVIDIA,ATI,图形一出了东西,估计都可以快速在OGRE里看到。一个图形引擎入门决好的教材。

上次看是1.0以前的版本。这个工程主要就是体现其名字---面向对象的图形引擎。所以各个部件都是从OO出发,最大可能体现OO在设计图形引擎中的作用。当然,也导致真实际用在工程里,不可避免的繁琐。真正的游戏工程其实不需要那么多变化的封装。另外,那可笑的从std::string派生的String类终于消失了。 但是1。2里突然发现又加了一个shared_ptr。而且是自己实现的,用于引用记数,与智能指针。。。。前一段为了让BOUNDCHECKER与STLPORT兼容,刨到STLPORT的string里面,发现内存池和replace new结合一用,基本让boundchecker的内存泄漏检查废柴。在STRING_OPTIMAZATION选项打开时(缺省),一旦需要string,STLPORT会先生成一个960的BUF,用来给replacement new用。可以想见,当用容器管理shared_ptr,在那shared_ptr曲折且隐讳的创建与销亡过程中,不知道会有多少废弃的对象沉尸于各种实现的stl memory pool中。一旦当外部iterator也好,什么也好,用错了一把,stl mem pool中的尸体就会被重新打捞上来被赋予僵尸复活的使命。而这一切还魂的过程将被shared_ptr,auto_ptr,non_ptr之类的东西掩盖得无影无踪。

几年里,给人印象深刻,几个月未找出,为数不多的几个BUG,都是因为对象生存周期使用容器管理而导致。。。。而错误其实都很低级。。。只不过淹没在STL内部那些晦涩拗口的优化实现里,无法及时发现。而这些错误又被STL自己的内存管理误打误撞的吃掉。导致重复一个错误花几个小时,甚至几天。尤其服务器,碰到STL里面自己throw然后悄无声息退掉程序,连COREDUMP都抓不到。错误就是一位弟兄越界访问了一个list.

作为软件工程,培训,学习,检测,走查,但什么也抵挡不住参差不齐的技术能力造成的破坏。当有些程序员把书写GP程序当成保护自己利益的手段时(因为其他人看不懂那些拗口的模板方法),或者卖弄聪明自鸣得意的乐趣时,那些初衷为更好解决复杂问题的手段,已经早已背离了方向。成为自己设计当初缺陷的牺牲品。只有STLPORT提供的容器越界检查(或者个人行为的SAFESTL),千篇一律晦涩不堪的STL代码风格,艰难的调试过程。工程中,一个人做到使用简单容器不出错误。根本没用。天才的人会指责为什么大家不都和他一样的智商。或者具有一样的经验与能力。但我怀疑,在VC的STL里提供一个assert( IS_VALID(iterator)) ,很困难么。毕竟STLPORT也时一个干的。这些都不是理所应当的。这就是STL的缺陷。我确实更关心软件工程,而不在乎软件科学如何的优雅。软件只是工具,目的就是要完成产品。在工程实践上,STL就是有它不少弊端。可以理解成这是对功能+性能追求的代价。

其实关键还在使用的态度。面对高级技术和工具,凡人很容易丧失了稳定心态。在能够勉强驾驭之前,就早已自鸣得意起来。但对于底层复杂丑陋,外表优雅方便的STL,或者其他永远诱人的各种高级技术,我们使用者永远得小心翼翼,心怀谦卑。那些发明这些东西的大师聪明程度不是我们能比的,他们也不需要在短短几年靠真刀真枪干出产品成家立业。对他们来说探索和发明的时间单位是年。而我们实践的单位是小时。对显而易见的荒谬视而不见,只被前瞻的华丽外皮麻醉是最可怕的。谁都在用std::vector,可几个人可以背诵出不同STL背后实现的优化内存池在外部对象生存管理错误时导致的精确后果?STL帮你实现的太多,也掩盖了太多。我用最丑陋的方法,达到目的,也比用最光鲜的技术导致5个人熬3个通宵解决2个月不出现BUG要强58倍。 理想的世界,学习曲线是忽略不计的,培训成本也是忽略的,员工成长的企业付出代价也是不计的。。。。。所以,这么不理想的BUG根本就不该出现。

其实还是,这么不理想的态度不要出现为好。




分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics