Question

这个问题更多的是理智检查，而不是＆＃34;请解决我的问题＆＃34;。我最近继承了几十年来由不同技能的不同开发人员编写的应用程序的代码。因此，试图弄清楚代码实际上想要做什么本身就是一个任务。

无论如何，我一次又一次地遇到了这种初始化模式，其中动态分配了内存，并且很快就会检查结果。由于此代码同时位于独立库和GUI中，因此以前的开发人员使用_STANDALONE宏来检查并相应地处理错误：

double *myArray = (double *) calloc(length, sizeof(double));
if (myArray == NULL)
 {
      strcat(message1, "myArray");
#ifdef _STANDALONE
      fprintf(stderr, "%s %s\n", message1, message2);
#else
      MessageBox(Window, message1, message2, MB_ICONEXCLAMATION);
#endif
      exit(EXIT_FAILURE);
}

注意：您可以假设message1和message2包含一个字符串，表示＆＃34;无法为变量分配内存...＆＃34;并且足够大，可以附加额外的gubbins。

这是理智检查。内存分配失败的最可能原因是操作系统没有任何备用。如果我们假设没有更多的内存备用，那么让我们来看看错误处理代码：

fprintf可能会也可能不会失败，具体取决于内部缓冲区的状态。我不知道发动机罩下的功能是什么，但我会假设它的内存要求很少。
我非常确定对MessageBox的调用会导致额外的内存分配，因为这会导致GUI对象出现在屏幕上。因此，这肯定会失败，因此无法实现开发人员的目的。

简而言之，我建议这样做可以更好地处理，但正确的路径并不是那么明显。

Answer 1

仅仅因为calloc失败并不意味着错误处理路径也会失败。

calloc可能失败了，因为请求很荒谬。例如，如果length * sizeof (double)溢出，calloc将失败。甚至可能即使没有溢出，请求也是一个不合理的内存量。在这些情况下，fprintf或MessageBox可能会有足够的可用内存。
在不知道fprintf和MessageBox的实现的情况下，您无法确定它们是否需要额外的内存分配。也许系统已经为它们保留了一些内存，以便在内存不足的情况下显示错误消息。

我不担心fprintf和MessageBox失败。如果你的系统真的没有足够的可用内存来处理fprintf或MessageBox，那么它可能会以许多其他方式吓坏。面对如此极端的记忆压力而终止是非常合理的。

Answer 2

这里最大的问题是＆＃34;长度＆＃34;的典型大小。如果长度经常非常高（让我们说1MB及以上），即使分配失败，也可以假设您仍有足够的内存用于简单的消息框。（并且检查的实际目标是防止这些非常大的分配）。

如果阵列通常很小，你最好不要显示任何方框。（你可以做的是预先分配所有必要的资源来显示窗口。但是不确定是否可以使用消息框）。

Answer 3

解决这个问题的一种方法是预先分配一些永远不会被使用的内存。

当你的内存不足时，你free这个区域，所以希望你的错误处理程序有足够的内存来完成它的工作。

处理失败的内存分配

3 个答案: