C语言难点揭秘[4]

让这些格式元素成为你日常工作的一部分。解决内存问题有多种方法:

专用库
语言
软件工具
硬件检查器

在这个整个领域里，我一直认为最有用、最有投资回报的就是考虑改进源代码的风格。它不需要昂贵的价格，也不需要严格的形式；你总是可以取消与内存无关的段的注释，但是显式注释当然需要影响内存的定义。简单加几个字可以让记忆结果更清晰，记忆编程也会有所提升。

我没有做对照实验来验证这种风格的效果。如果你的经历和我一样，你会发现不解释资源影响的策略简直让人无法忍受。这很简单，但是带来的好处太多了。

考试

它是对检测编码标准的补充。两者各有优势，但两者结合起来特别有效。聪明的C或C++专业人员甚至可以浏览不熟悉的源代码，以极低的成本检测内存问题。通过一点实践和适当的文本搜索，您可以快速验证balanced *alloc()和free()或new and delete的源代码体。手动查看这些内容通常会导致类似清单7中的问题。

清单7。困难的内存泄漏

static char * important _ pointer = null；
void f9()
{
if(！IMPORTANT _ pointer)
IMPORTANT _ pointer = malloc(IMPORTANT _ SIZE)；
...
if(条件)
/* Ooops！我们刚刚丢失了已经持有的引用
important_pointer。*/
important _ pointer = malloc(DIFFERENT _ SIZE)；
...
}

如果条件为真，简单地使用自动运行时工具无法检测到内存泄漏。仔细的来源分析可以从这样的条件中推断出正确的结论。我重复一下我写的关于风格的内容:尽管大量发表的关于内存问题的描述强调工具和语言，但对我来说，收获来自于“软的”以开发者为中心的过程变更。您在风格和检测方面所做的任何改进都可以帮助您理解自动化工具所生成的诊断。

静态的自动解析

当然，并不是只有人类能读懂源代码。您还应该将静态解析作为开发过程的一部分。静态解析是lint、strict compilation和一些商业产品执行的:扫描编译器接受的源文本和目标项，但这可能是错误的征兆。

让你的代码干净整洁。虽然lint已经过时，有一定的局限性，但是很多不使用它的程序员(或者它的更高级的后代)都犯了很大的错误。通常，您可以编写忽略lint的优秀专业质量的代码，但尝试这样做的结果通常会是一个重大错误。其中一些错误会影响记忆的正确性。相比于让客户先发现内存错误的成本，即使为这一类产品支付最贵的授权费也毫无意义。清除源代码。现在，即使lint标签的编码可能为你提供了所需的功能，但很可能有一个更简单的方法，既能满足lint，又相对强大，可移植性强。