习惯于GCC和Clang的人被宠坏了。外面不是很好。

这些年来，我被要求使用的过时的编译器吓坏了。公司和管理者通常采用极端保守的方法来更改编译器，甚至不会测试新的编译器（具有更好的标准遵从性和代码优化）是否能在他们的系统中工作。对于正在工作的开发人员来说，实际情况是，当你在编写代码时，你需要覆盖你的基础，不幸的是，如果你不能控制什么编译器可以应用于你的代码，那么使用mallocs是一个好习惯。

我还建议许多组织应用自己的编码标准，如果定义了编码标准，那么这应该是人们遵循的方法。在缺乏明确指导的情况下，我倾向于选择最有可能在任何地方编译，而不是盲目地遵守某个标准。

根据现行标准，这是不必要的，这一论点是非常有效的。但这一论点忽略了现实世界的现实性。在一个完全由当今标准统治的世界里，我们并没有编码，而是由我喜欢称之为“地方管理的现实领域”的实用性来控制。这比太空时代更加弯曲和扭曲

YMMV。

我倾向于将使用malloc作为防御操作。不漂亮，不完美，但总体安全。（老实说，如果你没有包含stdlib.h，那么你会遇到比强制执行malloc更多的问题！）。

不强制强制强制强制转换malloc的结果，因为它返回void*，并且void*可以指向任何数据类型。

void指针是泛型指针，C支持从void指针类型到其他类型的隐式转换，因此不需要显式类型转换。

然而，如果您希望相同的代码在不支持隐式转换的C++平台上完美兼容，则需要进行类型转换，因此这一切都取决于可用性。

你会选演员，因为：

它使您的代码在C和C++之间更具可移植性，正如SO的经验所示，许多程序员声称，当他们真正用C++（或C加本地编译器扩展）编写时，他们是在用C编写。如果不这样做，可能会隐藏一个错误：请注意所有的so示例，它们混淆了何时写入类型*和类型**。它会让你注意不到你没有#包含一个合适的头文件，这一想法让你错过了树的森林。这与说“不要担心你没能让编译器抱怨没有看到原型的事实——讨厌的stdlib.h才是真正需要记住的重要东西！”它强制进行额外的认知交叉检查。它将（所谓的）所需类型放在您对该变量的原始大小所做的算术旁边。我敢打赌，你可以做一个SO研究，表明malloc（）错误在有演员时被捕获的速度要快得多。与断言一样，揭示意图的注释可以减少错误。以机器可以检查的方式重复自己的行为通常是一个好主意。事实上，这就是断言，使用强制转换就是断言。断言仍然是我们获得正确代码的最通用技术，因为图灵多年前就提出了这个想法。

您不需要强制转换malloc的结果，因为这样做会给代码增加无意义的混乱。

人们之所以选择malloc的结果，最常见的原因是他们不确定C语言是如何工作的。这是一个警告信号：如果你不知道特定的语言机制是如何工作的，那么就不要猜测。查找或询问堆栈溢出。

一些意见：

空指针可以转换为任何其他指针类型，而无需显式转换（C11 6.3.2.3和6.5.16.1）。但是，C++不允许在void*和另一个指针类型之间进行隐式转换。因此，在C++中，演员阵容是正确的。但是如果你用C++编程，你应该使用new而不是malloc（）。而且您永远不应该使用C++编译器编译C代码。如果需要使用相同的源代码同时支持C和C++，请使用编译器开关来标记差异。不要试图用相同的代码来满足两种语言标准，因为它们不兼容。如果C编译器因为忘记包含标头而找不到函数，则会出现编译器/链接器错误。因此，如果您忘记包含<stdlib.h>，这没什么大不了的，您将无法构建您的程序。在遵循超过25年的标准版本的古代编译器上，忘记包含＜stdlib.h＞将导致危险行为。因为在那个古老的标准中，没有可见原型的函数隐式地将返回类型转换为int。显式地从malloc转换结果将隐藏这个错误。但这真的不是问题。你不是在使用一台25年前的计算机，那么你为什么要使用一台有25年历史的编译器呢？

在C语言中，可以将空指针分配给任何指针，这就是为什么不应该使用类型转换的原因。如果您想要“类型安全”分配，我可以推荐以下宏函数，这些函数我总是在C项目中使用：

#include <stdlib.h>
#define NEW_ARRAY(ptr, n) (ptr) = malloc((n) * sizeof *(ptr))
#define NEW(ptr) NEW_ARRAY((ptr), 1)

有了这些，你可以简单地说

NEW_ARRAY(sieve, length);

对于非动态数组，第三个必须的函数宏是

#define LEN(arr) (sizeof (arr) / sizeof (arr)[0])

这使得阵列环路更加安全和方便：

int i, a[100];

for (i = 0; i < LEN(a); i++) {
   ...
}