Question

在SO上阅读了很多更大，更受欢迎的主题，发现关于转换malloc（）的线程特别有趣。我只是因为这就是我被教导的原因而犯了我的回报罪。

我想知道的是，如果从malloc()转换回来可以隐藏不包括stdlib.h的错误，那么为什么答案不会被投射而不是始终确保stdlib.h 1}}被包括在内？

不是包括stdlib.h懒惰或不良做法，还是我错过了什么？我意识到还有其他原因没有投射，但这一点特别突出，因为看起来不好的做法在某种程度上被推广或接受。

那么，是否存在任何特定情况，如果实际需要，我们愿意不包括stdlib.h？我看到有很多人因为做这些事而被放下......铸造，但似乎没有人真的对这种疏忽有任何问题......有人可以解释为什么施放回报是不赞成的，却忽略了包括必要的标题是不？

我知道这是一个有争议的问题，并且过去一直是各种主题的主题。我试图回到这里的事情并打破旧习惯。

最后，任何信息来源都与目前的标准更加一致......我仍然在网上找到各种关于正在进行投射的示例，其中一些是最新的。

那里有很多相互矛盾的信息。你为什么不想包括stdlib.h或者对此如此傲慢，但对于演员却如此迂腐呢？

Answer 1

“强类型”的想法表明编译器应该能够在程序运行之前捕获程序员的大部分错误。没有做正确的#include是一个错误，编译器可以捕获（除非你无意中通过强制转换来压制它）。

“不要做这个错误”不是解决方案 - 总是会发生错误。

这种错误似乎是合理的，因为每当您向其添加动态内存分配时，检查代码是否已经具有正确的#include是很烦人的。人们往往会忘记（或“忘记”）做烦人的事情。

Answer 2

特别是在这样的情况下：

void addSomeData(someType **data) {
     ...
     ... manylines ...

     data = (someType *) malloc(sizeof(someType)*n);

应该是：

     *data = (someType *) malloc(sizeof(someType)*n);

这里的强制转换使编译器能够检查你是否真的想要做什么。此外，向代码添加冗余信息可能会增强或恶化可读性，这是一个问题，代码编写者和代码阅读器的个人风格。

另一方面，在这样的代码行中：

struct foo *bar = malloc(sizeof(struct foo));

演员可能确实没有任何好处。

然而，我认为这是一个过于简单和无关紧要的规则，malloc()的演员总是一个错误（！），作为SO索赔中引用得很多的答案。