在这个问题上,有人在评论中建议我不要使用malloc的结果。即,我应该这样做:

int *sieve = malloc(sizeof(*sieve) * length);

而不是:

int *sieve = (int *) malloc(sizeof(*sieve) * length);

为什么会这样?


当前回答

在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++) {
   ...
}

其他回答

尽可能在C语言中编程时最好做的事情是:

通过C编译器编译程序,并打开所有警告-Wall并修复所有错误和警告确保没有声明为auto的变量然后使用带有-Wall和-std=C++11的C++编译器对其进行编译。修复所有错误和警告。现在再次使用C编译器进行编译。您的程序现在应该在没有任何警告的情况下编译,并且包含更少的错误。

这个过程使您可以利用C++严格的类型检查,从而减少错误的数量。特别是,此过程强制您包含stdlib.否则您将得到

malloc未在此范围内声明

并且还强制你使用malloc的结果,否则你会得到

从void*到T的转换无效*

或者你的目标类型是什么。

用C而不是C++编写的唯一好处是

C具有明确规定的ABIC++可能会生成更多代码[异常、RTTI、模板、运行时多态性]

请注意,在理想情况下,当使用C所共有的子集和静态多态特性时,第二个缺点应该消失。

对于那些觉得C++严格规则不方便的人,我们可以使用带有推断类型的C++11特性

auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...

强制转换只适用于C++而不是C。如果您使用的是C++编译器,最好将其更改为C编译器。

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

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

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

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

YMMV。

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

在C语言中,您得到了从void*到任何其他(数据)指针的隐式转换。

正如其他人所说的,它不是C所需要的,而是C++所需要的。包括强制转换可以允许C程序或函数编译为C++。在C中,这是不必要的,因为void*会自动安全地升级为任何其他指针类型。但如果你当时就投了,如果你忘了包括,它会隐藏一个错误stdlib.h。这可能会导致崩溃(更糟的是,不会导致崩溃直到稍后在代码的某个完全不同的部分)。因为stdlib.h包含找到malloc的原型。在由于没有malloc的原型,标准要求C编译器假设malloc返回int。如果没有强制转换当该整数被分配给指针时发出警告;然而,在演员阵容中,这个警告并没有产生,隐藏了一个bug。