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

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

而不是:

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

为什么会这样?


当前回答

对我来说,这里的结论是,在C语言中使用malloc是完全没有必要的,但是如果你使用了C语言,它不会影响malloc,因为malloc仍然会为你分配你请求的内存空间。另一个原因是人们进行选角的原因或原因之一,这是为了使他们能够用C或C++编译相同的程序。

可能还有其他原因,但几乎可以肯定的是,其他原因迟早会让你陷入严重的麻烦。

其他回答

对我来说,这里的结论是,在C语言中使用malloc是完全没有必要的,但是如果你使用了C语言,它不会影响malloc,因为malloc仍然会为你分配你请求的内存空间。另一个原因是人们进行选角的原因或原因之一,这是为了使他们能够用C或C++编译相同的程序。

可能还有其他原因,但几乎可以肯定的是,其他原因迟早会让你陷入严重的麻烦。

在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语言的理解)告诉我,这是绝对没有必要的,但只用于绝对具体,并让学生们养成绝对具体的心态。从本质上讲,强制转换不会改变它的工作方式,它完全按照它所说的做,分配内存,强制转换不影响它,你会得到相同的内存,即使你错误地将它强制转换为其他东西(并以某种方式规避编译器错误),C也会以同样的方式访问它。

编辑:铸造有一定的意义。当您使用数组表示法时,生成的代码必须知道要到达下一个元素的开头,需要前进多少个内存位置,这是通过强制转换实现的。通过这种方式,您可以知道,对于double,您可以提前8个字节,而对于int,则可以提前4个字节,依此类推。因此,如果您使用指针表示法,则不会产生任何影响,在数组表示法中,这是必要的。

在C语言中,不需要强制转换malloc的返回值。malloc返回的指向void的指针会自动转换为正确的类型。但是,如果您想用C++编译器编译代码,则需要强制转换。社区中的首选替代方案是使用以下方法:

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

另外,如果你改变了筛子的类型,你就不用担心改变表达式的右边。

正如人们所指出的那样,铸件是不好的。尤其是指针强制转换。

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

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

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

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

YMMV。

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