user-0 提问: c语言的编程清晰与资源利用的思路，是不是可行？这方面以前就想到过，现在觉得比较有必要，但好像关心的不多。

回复:
user: user-0
content: 主贴中下面的描述  malloc 失败 retvar=-1 用 goto 跳转到 1号代码段结束  不准确，应改为  malloc 失败 retvar=-1 用 goto 跳转到 函数代码段结束

user: user-1
content: 年轻人，多看书，少空想，这种思路是已经被C++淘汰N久的东西了，auto_ptr

user: user-2
content: 请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。  意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。  试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。  所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。  结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。  程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George  前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。

user: user-0
content: 引用 2 楼 anhuizhuanjiao 的回复:年轻人，多看书，少空想，这种思路是已经被C++淘汰N久的东西了，auto_ptr 引用 2 楼 anhuizhuanjiao 的回复:年轻人，多看书，少空想，这种思路是已经被C++淘汰N久的东西了，auto_ptr    我用c++编过一些程序，我的意思是在尽可能用简单的技术情况下实现尽可能自动化的快速的资源释放，同时几乎是“硬性地”保持代码结构清晰，而且自动化很重要，这样的思路基本天然具有资源尽量快速自动释放的要求，我看了一段新的智能指针 unique_ptr 的好象是比较有权威性的代码，    memobj1 new  memobj2 new  。。。。。。。。。   memobj2 move from memobj1    //此处比较隐蔽地释放开始时 memobj2 的资源 但是把 memobj2 的衣服套在了 menobj1 所代表的资源上，而 memobj1 的衣服不再被需要了  这时开始时 memobj1 所分配的资源还在        所以  memobj1  存续期是完全包含 memobj2 的存续期，这与我说的犬牙交错，即内部对象突破包含它的外部对象的作用范围的情况不符。由于是比较权威的发布，所以我觉得智能指针设计的本意重心可能并不是为了平衡代码清晰与资源尽量及时释放的冲突，可能重点是为了防止内存泄漏以及多线程资源并发访问类似的问题的。  我用  unique_ptr 大概写了一段伪代码，来演示怎么应对内部对象突破包含它的外部对象的作用范围的情况，还要使代码尽量清晰，资源尽量及时释放。     memobj1 new  memobj2 new  。。。。。。。。。   memobj1 move from memobj2    //此处比较隐蔽地释放开始时 memobj1 的资源 但是把 memobj1 的衣服套在了 menobj2 所代表的资源上，而 memobj2 的衣服不再被需要了 memobj2 delete  做一个伪代码,提示 memobj2 的衣服不再被使用，从而使代码尽量清晰。  memobj1 delete    //此处比较隐蔽地释放开始时 memobj2 的资源 但是 memobj2 的资源披上了 menobj1 的衣服，从而使代码尽量清晰    可以看出，这样的代码与用类似 c语言 代码比较基本并没有什么比较大的简洁性，面向对象的特性使对象在到达作用范围之外被析构并释放资源，但如果在作用范围内，还是需要手动释放资源的，也没什么自动性，我的意思是能用简单的工具就尽量用简单的工具，    我再比较详细地用类似c语言的代码演示怎么应对内部对象突破包含它的外部对象的作用范围的情况：     memvar1 malloc  在memvar1中找一个字符串 str1  如果找到 str1 那么  		 memvar2 malloc 		 memvar2     被注入 一个文件名 ，文件名所标示的文件被 注入 memvar1 的内容， 		 memvar3=memvar2 memvar2=memvar1 memvar1=memvar3 		 这时 memvar1 占用的资源不再被需要了，但为了代码的简洁明晰，交换 memvar1 与 memvar2 的值，并进行下面的操作 		 memvar2 free      由于前面的交换， memvar2 的本质是 memvar1 ,即 memvar1 穿着 memvar2 的衣服向系统提出释放自己占用的资源 这样一来及时地释放了 memvar1 所占用的资源，又使代码结构清晰  memvar1 free  由于前面的交换， memvar1 的本质是 memvar2 ,即 memvar2 穿着 memvar1 的衣服向系统提出释放自己占用的资源 这样一来及时地释放了 memvar2 所占用的资源，又使代码结构清晰    代码层面 内部对象 不涉及到外部，有面相对象的意味，尽量平衡节省资源与代码清晰易懂之间的冲突。

user: user-0
content: 引用 1 楼 zhao4zhong1 的回复:请牢记：源代码本身的书写是否结构化或面向对象或符合设计模式或敏捷…并不重要，重要的是你是否使用结构化或面向对象或符合设计模式或敏捷…的方法命名标识符、阅读、修改、检查、测试源代码。  意思是你程序结构看上去再合理，再简洁，也不一定比看上去一团乱麻的程序结构在运行或修改时更不易出错，更方便修改，出错了更容易找到哪里出错和具体出错的原因，更容易改正错误。  试对比 图书馆（对图书的分类够结构化了吧） 和 搜索引擎（可看作是扁平化任何结构数据，仅支持全文检索） 哪个处理信息更方便、更高效。  所以 与其费劲去重构代码让其看上去更简洁、更合理 不如费劲学习grep、sed、awk、……这类全文搜索和批处理编辑的工具。  结构越复杂，越难修改，越难除错。 有时（甚至大多数时候），看上去越合理、越简洁的代码，运行起来性能越差，出错时查找原因越难，找到出错原因后改正越费劲。  程序员要做的不是尽力避免错误，而是聚焦在快速发现并改正错误。真正以快速方式轻易解决错误，“快速的失败”远胜过“预防错误”。Fred George  前微软C#编辑器的开发主管Jay Bazuzi列出的一些有助于找到正确方向的问题；他觉得前同事们应该用这些问题来问自己；实际上不管在哪里工作的开发者们都应该经常问问自己这些问题： ◆“要保证这个问题不会再出现，我该怎么做？” ◆“要想少出些Bug，我该怎么做？” ◆“要保证Bug容易被修复，我该怎么做？” ◆“要保持对变化的快速响应，我该怎么做？” ◆“要保证我的软件的运行速度，我该怎么做？” 如果大多数团队都能不时问一下自己，必定会从中得益，因为这些都是真正强而有力的问题。   我觉得编程的目的基本是实现一个目标，在尽量减少错误与尽量快速应用并推向市场等等等等类似的事情这样两个目标之间我的想法是尽量减少错误，我提出的思路可能开发速度比较慢，所以可能需要很多人稳妥地按照这样的思路开发，如果人够多，并能稳妥运用这样的方法（当然方法也许还有改进），应该能以非常稳定的速度源源不断地持续生产出比较好的产品。这种思路好像八股文，但是这是在尽量平衡追求收益与减少损失之间的冲突。 性能问题我觉得这样的思路开发主要是开发的速度慢，程序运行的速度可能会受一些影响，但是如果还要提高速度，那应用的技术可能会是比较极端的技巧了，这样极端的技术那基本就适合在画面效果非常非常好的游戏这样的程序中运用了，在工厂医院这样的场所应用的软件我觉得不适合应用太极端极致的技巧，往深里说多备份系统可能能缓解极端的技巧所带来的可能的副作用，这样就引入了新的思路，可以另外讨论。