C/C++ 最大难点揭秘：编程的祸根！
逆锋起笔
共 11127字，需浏览 23分钟
·
2021-09-19 03:01
引言
但事实并非如此。本文将让您在短时间内理解与良好内存相关的编码的所有本质：
正确的内存管理的重要性
在可以使用 C 或 C++ 的地方，也广泛支持使用其他许多通用语言(如 Java?、Ruby、Haskell、C#、Perl、Smalltalk 等)，每种语言都有众多的爱好者和各自的优点。但是，从计算角度来看，每种编程语言优于 C 或 C++ 的主要优点都与便于内存管理密切相关。与内存相关的编程是如此重要，而在实践中正确应用又是如此困难，以致于它支配着面向对象编程语言、功能性编程语言、高级编程语言、声明性编程语言和另外一些编程语言的所有其他变量或理论。
与少数其他类型的常见错误一样，内存错误还是一种隐性危害：它们很难再现，症状通常不能在相应的源代码中找到。例如，无论何时何地发生内存泄漏，都可能表现为应用程序完全无法接受，同时内存泄漏不是显而易见。
因此，出于所有这些原因，需要特别关注 C 和 C++ 编程的内存问题。让我们看一看如何解决这些问题，先不谈是哪种语言。
内存错误的类别
这是所有类型。即使迁移到 C++ 面向对象的语言，这些类型也不会有明显变化;无论数据是简单类型还是 C 语言的 struct或 C++ 的类，C 和 C++ 中内存管理和引用的模型在原理上都是相同的。以下内容绝大部分是“纯 C”语言，对于扩展到 C++ 主要留作练习使用。
void f1(char *explanation)
{
char p1;
p1 = malloc(100);
(void) sprintf(p1,
"The f1 error occurred because of '%s'.",
explanation);
local_log(p1);
}
在实际的 C 和 C++ 编程中，这不足以影响您对 malloc()或 new的使用，本部分开头的句子提到了“资源”不是仅指“内存”，因为还有类似以下内容的示例(请参见清单 2)。FILE句柄可能与内存块不同，但是必须对它们给予同等关注：
清单 2. 来自资源错误管理的潜在堆内存丢失
int getkey(char *filename)
{
FILE *fp;
int key;
fp = fopen(filename, "r");
fscanf(fp, "%d", &key);
return key;
}
错误分配的管理不是很困难。下面是一个示例(请参见清单 3)：
清单 3. 未初始化的指针
void f2(int datum)
{
int *p2;
/* Uh-oh! No one has initialized p2. */
*p2 = datum;
...
}
在此错误类型中存在多个变种。free()释放的内存比 malloc()更频繁(请参见清单 4)：
/* Allocate once, free twice. */
void f3()
{
char *p;
p = malloc(10);
...
free(p);
...
free(p);
}
/* Allocate zero times, free once. */
void f4()
{
char *p;
/* Note that p remains uninitialized here. */
free(p);
}
void f8()
{
struct x *xp;
xp = (struct x *) malloc(sizeof (struct x));
xp.q = 13;
...
free(xp);
...
/* Problem! There's no guarantee that
the memory block to which xp points
hasn't been overwritten. */
return xp.q;
}
即使影响提前释放内存范围的代码已本地化，内存的使用仍然可能取决于应用程序甚至(在极端情况下)不同进程中的其他执行位置。
悬空指针可能发生在以微妙方式使用内存的代码中。结果是，即使内存在释放后立即被覆盖，并且新指向的值不同于预期值，也很难识别出新值是错误值。悬空指针不断威胁着 C 或 C++ 程序的运行状态。
内存编程的策略
清单 6. 识别资源的源代码示例
/********
* ...
*
* Note that any function invoking protected_file_read()
* assumes responsibility eventually to fclose() its
* return value, UNLESS that value is NULL.
*
********/
FILE *protected_file_read(char *filename)
{
FILE *fp;
fp = fopen(filename, "r");
if (fp) {
...
} else {
...
}
return fp;
}
/*******
* ...
*
* Note that the return value of get_message points to a
* fixed memory location. Do NOT free() it; remember to
* make a copy if it must be retained ...
*
********/
char *get_message()
{
static char this_buffer[400];
...
(void) sprintf(this_buffer, ...);
return this_buffer;
}
/********
* ...
* While this function uses heap memory, and so
* temporarily might expand the over-all memory
* footprint, it properly cleans up after itself.
*
********/
int f6(char *item1)
{
my_class c1;
int result;
...
c1 = new my_class(item1);
...
result = c1.x;
delete c1;
return result;
}
/********
* ...
* Note that f8() is documented to return a value
* which needs to be returned to heap; as f7 thinly
* wraps f8, any code which invokes f7() must be
* careful to free() the return value.
*
********/
int *f7()
{
int *p;
p = f8(...);
...
return p;
}
硬件检查器在这整个领域中，我始终认为最有用并且投资回报率最大的是考虑改进源代码的风格。它不需要昂贵的代价或严格的形式;可以始终取消与内存无关的段的注释，但影响内存的定义当然需要显式注释。添加几个简单的单词可使内存结果更清楚，并且内存编程会得到改进。
我没有做受控实验来验证此风格的效果。如果您的经历与我一样，您将发现没有说明资源影响的策略简直无法忍受。这样做很简单，但带来的好处太多了。
检测是编码标准的补充。二者各有裨益，但结合使用效果特别好。机灵的 C 或 C++ 专业人员甚至可以浏览不熟悉的源代码，并以极低的成本检测内存问题。通过少量的实践和适当的文本搜索，您能够快速验证平衡的 *alloc()和 free()或者 new和 delete的源主体。人工查看此类内容通常会出现像清单 7中一样的问题。
清单 7. 棘手的内存泄漏
static char *important_pointer = NULL;
void f9()
{
if (!important_pointer)
important_pointer = malloc(IMPORTANT_SIZE);
...
if (condition)
/* Ooops! We just lost the reference
important_pointer already held. */
important_pointer = malloc(DIFFERENT_SIZE);
...
}
希望让您的代码无 lint。尽管 lint已过时，并有一定的局限性，但是，没有使用它(或其较高级的后代)的许多程序员犯了很大的错误。通常情况下，您能够编写忽略 lint的优秀的专业质量代码，但努力这样做的结果通常会发生重大错误。其中一些错误影响内存的正确性。与让客户首先发现内存错误的代价相比，即使对这种类别的产品支付最昂贵的许可费也失去了意义。清除源代码。现在，即使 lint标记的编码可能向您提供所需的功能，但很可能存在更简单的方法，该方法可满足 lint，并且比较强键又可移植。
由于这些原因，我们催促 C 和 C++ 程序员为解决内存问题先了解一下自己的源。在这完成之后，才去考虑库。
使用几个库能够编写常规的 C 或 C++ 代码，并保证改进内存管理。Jonathan Bartlett 在 developerWorks 的 2004 评论专栏中介绍了主要的候选项，可以在下面的参考资料部分获得。库可以解决多种不同的内存问题，以致于直接对它们进行比较是非常困难的;这方面的常见主题包括垃圾收集、智能指针和智能容器。大体上说，库可以自动进行较多的内存管理，这样程序员可以犯更少的错误。
我对内存库有各种感受。他们在努力工作，但我看到他们在项目中获得的成功比预期要小，尤其在 C 方面。我尚未对这些令人失望的结果进行仔细分析。例如，业绩应该与相应的手动内存管理一样好，但是这是一个灰色区域——尤其在垃圾收集库处理速度缓慢的情况下。通过这方面的实践得出的最明确的结论是，与 C 关注的代码组相比，C++ 似乎可以较好地接受智能指针。
本文主要讨论了基于软件的内存工具。还有硬件内存调试器;在非常特殊的情况下(主要是在使用不支持其他工具的专用主机时)才考虑它们。
市场上的软件内存工具包括专有工具(如 IBM Rational Purify 和 Electric Fence)和其他开放源代码工具。其中有许多可以很好地与 AIX 和其他操作系统一起使用。
所有内存工具的功能基本相同：构建可执行文件的特定版本(很像在编译时通过使用 -g标记生成的调试版本)、练习相关应用程序和研究由工具自动生成的报告。请考虑如清单 8所示的程序。
清单 8. 示例错误
int main()
{
char p[5];
strcpy(p, "Hello, world.");
puts(p);
}
结束语
逆锋起笔是一个专注于程序员圈子的技术平台，你可以收获最新技术动态、最新内测资格、BAT等大厂的经验、精品学习资料、职业路线、副业思维，微信搜索逆锋起笔关注！
评论