我要转换 malloc 的结果吗？

在 C 中，您可以将 void 指针隐式转换为任何其他类型的指针，因此不需要强制转换。使用一个可能会向不经意的观察者暗示需要一个是有某种原因的，这可能会产生误导。

---

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

人们选择 malloc 结果的最常见原因是他们不确定 C 语言的工作原理。这是一个警告信号：如果您不知道特定语言机制是如何工作的，那么不要猜测。在 Stack Overflow 上查找或询问。

一些评论：

void 指针可以转换为/从任何其他指针类型转换，无需显式转换（C11 6.3.2.3 和 6.5.16.1）。

然而，C++ 不允许在 void* 和另一个指针类型之间进行隐式转换。所以在 C++ 中，强制转换是正确的。但是如果你用 C++ 编程，你应该使用 new 而不是 malloc()。而且你永远不应该使用 C++ 编译器来编译 C 代码。如果您需要使用相同的源代码同时支持 C 和 C++，请使用编译器开关来标记差异。不要试图用相同的代码来满足两种语言标准，因为它们不兼容。

如果 C 编译器因为您忘记包含标头而找不到函数，您将收到一个编译器/链接器错误。因此，如果您忘记包含 这没什么大不了的，您将无法构建您的程序。

在遵循超过 25 年历史的标准版本的古代编译器上，忘记包含 会导致危险行为。因为在那个古老的标准中，没有可见原型的函数会隐式地将返回类型转换为 int。然后显式地从 malloc 转换结果会隐藏这个错误。但这真的不是问题。您没有使用 25 年的计算机，那么为什么要使用 25 年的编译器呢？

---

在 C 中，您会得到从 void * 到任何其他（数据）指针的隐式转换。

---

现在不需要强制转换 malloc() 返回的值，但我想补充一点，似乎没有人指出：

在古代，即在 ANSI C 提供 void * 作为指针的泛型类型之前，char * 是这种用法的类型。在这种情况下，强制转换可以关闭编译器警告。

参考：C FAQ

---

只是添加我的经验，学习计算机工程，我看到我看到用 C 编写的两三个教授总是使用 malloc，但是我问的那个（具有巨大的 CV 和对 C 的理解）告诉我这是绝对没有必要的，但是以前只是绝对具体，让学生进入绝对具体的心态。本质上，强制转换不会改变它的工作方式，它完全按照它说的去做，分配内存，并且强制转换不会影响它，你得到相同的内存，即使你错误地将它强制转换为其他东西（并且以某种方式逃避编译器错误）C 将以相同的方式访问它。

编辑：铸造有一定的意义。当您使用数组表示法时，生成的代码必须知道它必须提前多少内存位置才能到达下一个元素的开头，这是通过强制转换来实现的。这样，您就知道对于 double，您会提前 8 个字节，而对于 int，您会提前 4 个字节，依此类推。因此，如果您使用指针表示法，它没有效果，在数组表示法中它变得必要。

---

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

---

这就是 The GNU C Library Reference 手册所说的：

您可以将 malloc 的结果存储到任何指针变量中而无需强制转换，因为 ISO C 在必要时会自动将类型 void * 转换为另一种类型的指针。但是在赋值运算符以外的上下文中，或者如果您可能希望您的代码在传统 C 中运行，则强制转换是必要的。

确实 ISO C11 standard (p347) 是这么说的：

如果分配成功，则返回的指针经过适当对齐，以便可以将其分配给具有基本对齐要求的任何类型对象的指针，然后用于访问分配的空间中的此类对象或此类对象的数组（直到空间被显式释放）

---

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

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

---

返回的类型是 void*，可以将其强制转换为所需的数据指针类型以便可解引用。

---

这取决于编程语言和编译器。如果您在 C 中使用 malloc，则无需进行类型转换，因为它会自动进行类型转换。但是，如果您使用的是 C++，那么您应该键入 cast，因为 malloc 将返回一个 void* 类型。

---

在 C 语言中，可以将 void 指针分配给任何指针，这就是不应该使用类型转换的原因。如果你想要“类型安全”的分配，我可以推荐以下宏函数，我总是在我的 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++) {
   ...
}

---

习惯 GCC 和 Clang 的人都被宠坏了。那里并不是那么好。

多年来，我被要求使用的年代久远的编译器吓坏了。公司和管理人员通常会采用极其保守的方法来更改编译器，甚至不会测试新的编译器（具有更好的标准合规性和代码优化）是否可以在他们的系统中工作。工作开发人员的实际情况是，当您编写代码时，您需要覆盖您的基础，不幸的是，如果您无法控制可以将哪些编译器应用于您的代码，那么强制转换 malloc 是一个好习惯。

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

在当前标准下没有必要的论点是非常有效的。但这个论点忽略了现实世界的实用性。我们不是在一个完全由当时的标准统治的世界中编码，而是由我喜欢称之为“本地管理的现实领域”的实用性来编码。这比时空更弯曲和扭曲。 :-)

YMMV。

我倾向于将 malloc 转换为防御性操作。不漂亮，不完美，但通常是安全的。 （老实说，如果你没有包含 stdlib.h 那么你比强制转换 malloc 有更多的问题！）。

---

这个问题是基于意见的滥用的主题。

有时我会注意到这样的评论：

不要转换 malloc 的结果

或者

为什么你不投射 malloc 的结果

关于 OP 使用强制转换的问题。评论本身包含指向此问题的超链接。

这在任何情况下都是不恰当和不正确的。当这真的是一个人自己的编码风格问题时，没有对错之分。

为什么会这样？

它基于两个原因：

这个问题确实是基于意见的。从技术上讲，这个问题应该在几年前以基于意见的方式结束。一个“我要”或“我不要”或等效的“我应该”或“我不应该”的问题，如果没有自己观点的态度，你就无法专注地回答。关闭问题的原因之一是因为它“可能会导致基于意见的答案”，正如这里所展示的那样。许多答案（包括@unwind 最明显和公认的答案）要么完全或几乎完全基于意见（如果你自己铸造或重复自己会被添加到你的代码中的神秘“混乱”会很糟糕）并显示省略演员表的明确而集中的倾向。他们一方面争论演员阵容的冗余，但更糟糕的是，他们争论解决由编程本身的错误/失败引起的错误——如果想使用 malloc() 就不要#include 。

我想对所讨论的一些观点提出真实的看法，而不是我的个人意见。有几点需要特别注意：

这样一个非常容易陷入自己观点的问题需要一个中性利弊的答案。不仅有缺点也有优点。此答案中列出了优缺点的一个很好的概述：https://stackoverflow.com/a/33047365/12139179 （由于这个原因，我个人认为这是迄今为止最好的答案。）

最多遇到的一个原因是省略演员表的原因是演员表可能隐藏了一个错误。如果有人使用返回 int 的隐式声明 malloc()（隐式函数自 C99 以来已从标准中消失）和 sizeof(int) != sizeof(int*)，如本问题所示Why does this code segfault on 64-bit架构但在 32 位上工作正常？演员会隐藏一个错误。虽然这是真的，但它只显示了故事的一半，因为演员的遗漏只会是一个更大的错误的前瞻性解决方案 - 不包括使用 malloc() 时的 stdlib.h。这永远不会是一个严重的问题，如果你，使用符合 C99 或更高版本的编译器（推荐并且应该是强制性的），并且当你想使用 malloc( ) 在您的代码中，这本身就是一个巨大的错误。

有些人争论 C 代码的 C++ 合规性，因为强制转换在 C++ 中是必需的。首先要笼统地说：用 C++ 编译器编译 C 代码并不是一个好习惯。 C 和 C++ 实际上是两种完全不同的语言，具有不同的语义。但是，如果您真的想要/需要使 C 代码与 C++ 兼容，反之亦然，请使用编译器开关而不是任何强制转换。由于演员表倾向于被宣布为多余甚至有害，我想重点关注这些问题，这很好地说明了演员表有用甚至是必要的原因：https://stackoverflow.com/a/34094068/12139179 https ://stackoverflow.com/a/36297486/12139179 https://stackoverflow.com/a/33044300/12139179

当您的代码，分别分配指针的类型（以及强制转换的类型）发生变化时，强制转换可能是无益的，尽管这在大多数情况下不太可能。然后您还需要维护/更改所有强制转换，如果您的代码中有几千次调用内存管理函数，这真的可以总结并降低维护效率。

概括：

事实是，如果分配的指针指向具有基本对齐要求的对象（包括所有对象中的大多数），则根据 C 标准（从 ANSI-C (C89/C90) 开始），强制转换是多余的。

您不需要进行强制转换，因为在这种情况下指针会自动对齐：

“连续调用aligned_alloc、calloc、malloc和realloc函数分配的存储顺序和连续性是未指定的。如果分配成功返回的指针被适当对齐，以便它可以分配给指向任何类型对象的指针一个基本的对齐要求，然后用于访问分配的空间中的此类对象或此类对象的数组（直到空间被显式释放）。资料来源：C18，§7.22.3/1

“基本对齐是小于或等于 _Alignof (max_align_t) 的有效对齐。所有存储持续时间的对象的实现都应支持基本对齐。以下类型的对齐要求应为基本对齐： — 所有原子的、合格的, 或不合格的基本类型； — 所有原子的、合格的或不合格的枚举类型； — 所有原子的、合格的或不合格的指针类型； — 其元素类型具有基本对齐要求的所有数组类型；57) — 第 7 条中规定的所有类型作为完整的对象类型；——所有结构或联合类型，其所有元素都具有具有基本对齐要求的类型，并且没有一个元素具有指定非基本对齐的对齐方式的对齐说明符。如 6.2.1 中所述，后面的声明可能会隐藏先前的声明。”资料来源：C18，§6.2.8/2

但是，如果您为扩展对齐要求的实现定义的对象分配内存，则需要进行强制转换。

扩展对齐由大于 _Alignof (max_align_t) 的对齐表示。是否支持任何扩展对齐以及支持它们的存储持续时间是实现定义的。具有扩展对齐要求的类型是过度对齐类型。58) 源。 C18，§6.2.8/3

其他一切都取决于具体的用例和自己的意见。

请注意你如何教育自己。

我建议您首先仔细阅读所有的答案（以及他们可能指出失败的评论），然后如果您或如果您不投malloc() 在特定情况下。

请注意：

这个问题没有正确和错误的答案。这是风格问题，您自己决定选择哪种方式（当然，如果您没有受到教育或工作的强迫）。请注意这一点，不要让欺骗你。

最后一点：我最近投票决定以基于意见的方式结束这个问题，多年来确实需要。如果您获得关闭/重新打开特权，我也想邀请您这样做。

---

不，您不会强制转换 malloc() 的结果。

一般来说，您不会向 void * 投射或从 void * 投射。

不这样做的一个典型原因是，#include <stdlib.h> 失败可能会被忽视。由于 C99 使 隐式函数声明 非法，这在很长一段时间内都不再是问题，因此如果您的编译器至少符合 C99，您将收到一条诊断消息。

但是有一个更强有力的理由不引入不必要的指针转换：

在 C 中，指针转换几乎总是错误的。这是因为以下规则（N1570 中的§6.5 p7，C11 的最新草案）：

对象的存储值只能由具有以下类型之一的左值表达式访问： — 与对象的有效类型兼容的类型， — 与对象的有效类型兼容的类型的限定版本， —对应于对象有效类型的有符号或无符号类型， — 对应于对象有效类型的限定版本的有符号或无符号类型， — 聚合或联合类型，包括一个其成员中的上述类型（递归地，包括子聚合或包含联合的成员），或者 - 字符类型。

这也称为严格别名规则。所以下面的代码是未定义的行为：

long x = 5;
double *p = (double *)&x;
double y = *p;

而且，有时令人惊讶的是，以下内容也是如此：

struct foo { int x; };
struct bar { int x; int y; };
struct bar b = { 1, 2};
struct foo *p = (struct foo *)&b;
int z = p->x;

有时，您确实需要转换指针，但鉴于严格的别名规则，您必须非常小心。因此，代码中任何出现的指针转换都是您必须仔细检查其有效性的地方。因此，您永远不会编写不必要的指针转换。

tl;博士

简而言之：因为在 C 语言中，任何指针转换的出现都应该为需要特别注意的代码提出一个危险信号，所以您永远不应该编写不必要的指针转换。

旁注：

在某些情况下，您实际上需要强制转换为 void *，例如，如果您想打印一个指针： int x = 5; printf("%p\n", (void *)&x);强制转换在这里是必要的，因为 printf() 是一个可变参数函数，所以隐式转换不起作用。

在 C++ 中，情况有所不同。在处理派生类的对象时，转换指针类型有些常见（并且正确）。因此，在 C++ 中，与 void * 之间的转换不是隐式的，这是有道理的。 C++ 有一整套不同风格的转换。

---

我加入演员表只是为了表明不赞成类型系统中的丑陋漏洞，它允许以下代码片段之类的代码在没有诊断的情况下编译，即使没有使用演员表来导致错误的转换：

double d;
void *p = &d;
int *q = p;

我希望那不存在（并且它在 C++ 中不存在），所以我投了。它代表了我的品味和我的编程政治。我不仅投了一个指针，而且还有效地投了一张选票，然后casting out demons of stupidity。如果我不能实际上 cast out stupidity，那么至少让我以抗议的姿态表达希望这样做。

事实上，一个好的做法是用返回 unsigned char * 的函数包装 malloc（和朋友），并且基本上永远不要在代码中使用 void *。如果您需要指向任何对象的通用指针，请使用 char * 或 unsigned char *，并进行双向转换。也许可以放纵的一种放松方式是使用 memset 和 memcpy 等不带强制转换的函数。

关于转换和 C++ 兼容性的主题，如果您编写代码以使其同时编译为 C 和 C++（在这种情况下，您必须在将 malloc 的返回值分配给某物时对其进行转换除了 void *)，您可以为自己做一件非常有帮助的事情：您可以使用宏进行转换，在编译为 C++ 时转换为 C++ 样式转换，但在编译为 C 时减少为 C 转换：

/* In a header somewhere */
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif

如果您坚持使用这些宏，那么在您的代码库中搜索这些标识符的简单 grep 将显示您的所有演员表在哪里，因此您可以查看其中是否有任何不正确。

然后，如果您定期使用 C++ 编译代码，它将强制使用适当的强制转换。例如，如果您使用 strip_qual 只是为了删除 const 或 volatile，但程序发生了变化，现在涉及到类型转换，您将获得诊断，并且您必须使用强制转换组合以获得所需的转换。

为了帮助您遵守这些宏，GNU C++（不是 C！）编译器有一个漂亮的特性：为所有出现的 C 样式转换生成一个可选诊断。

-Wold-style-cast (C++ and Objective-C++ only)
         Warn if an old-style (C-style) cast to a non-void type is used
         within a C++ program.  The new-style casts (dynamic_cast,
         static_cast, reinterpret_cast, and const_cast) are less vulnerable
         to unintended effects and much easier to search for.

如果您的 C 代码编译为 C++，您可以使用此 -Wold-style-cast 选项找出所有可能出现在代码中的 (type) 强制转换语法，并通过将其替换为以下选项来跟进这些诊断上述宏（或组合，如有必要）。

这种转换处理是在“干净的 C”中工作的最大的独立技术理由：组合 C 和 C++ 方言，这反过来在技术上证明了转换 malloc 的返回值是合理的。

---

尽可能在 C 中编程时最好的做法是：

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

此过程允许您利用 C++ 严格类型检查，从而减少错误数量。特别是，此过程会强制您包含stdlib.h，否则您将获得

malloc 未在此范围内声明

并且还强制您转换 malloc 的结果，否则您将得到

从 void* 到 T* 的无效转换

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

我能找到用 C 而不是 C++ 编写的唯一好处是

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

请注意，在理想情况下，当将 C 的公共子集与静态多态特性一起使用时，第二个缺点应该消失。

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

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

---

我更喜欢做演员，但不是手动的。我最喜欢使用 glib 中的 g_new 和 g_new0 宏。如果不使用 glib，我会添加类似的宏。这些宏在不影响类型安全的情况下减少了代码重复。如果类型错误，您将在非 void 指针之间获得隐式转换，这将导致警告（C++ 中的错误）。如果您忘记包含定义 g_new 和 g_new0 的标头，则会收到错误消息。 g_new 和 g_new0 都采用相同的参数，而 malloc 采用的参数少于 calloc。只需添加 0 即可获得零初始化内存。代码可以用 C++ 编译器编译而无需更改。

---

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

---

malloc 的强制转换在 C 中是不必要的，但在 C++ 中是强制性的。

在 C 中不需要强制转换，因为：

在 C 的情况下，void * 会自动且安全地提升为任何其他指针类型。

如果您忘记包含 ，它可以隐藏错误。这可能会导致崩溃。

如果指针和整数的大小不同，那么您正在通过强制转换隐藏警告，并且可能会丢失返回地址的位。

如果指针的类型在其声明时发生更改，则可能还需要更改调用和强制转换 malloc 的所有行。

另一方面，强制转换可能会增加程序的可移植性。即，它允许将 C 程序或函数编译为 C++。

---

void 指针背后的概念是它可以转换为任何数据类型，这就是 malloc 返回 void 的原因。此外，您必须注意自动类型转换。因此，尽管您必须这样做，但并不强制强制转换指针。它有助于保持代码清洁并有助于调试

---

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

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

---

如前所述，C 不需要它，但 C++ 需要它。包括强制转换可能允许 C 程序或函数编译为 C++。在 C 中这是不必要的，因为 void * 会自动且安全地提升为任何其他指针类型。但是如果你在那时进行转换，如果你忘记包含 stdlib.h，它可能会隐藏一个错误。这可能会导致崩溃（或者，更糟糕的是，直到稍后在代码的某些完全不同的部分中才会导致崩溃）。因为 stdlib.h 包含了 malloc 的原型，所以找到了。在没有 malloc 原型的情况下，标准要求 C 编译器假定 malloc 返回一个 int。如果没有强制转换，则在将此整数分配给指针时发出警告；但是，使用演员表时，不会产生此警告，从而隐藏了一个错误。

---

malloc 的主要问题是获得正确的尺寸。

从 malloc() 返回的内存是无类型，并且由于简单的强制转换，它不会神奇地获得有效类型。

我想这两种方法都很好，选择应该取决于程序员的意图。

如果为类型分配内存，则使用强制转换。

ptr = (T*)malloc(sizeof(T));

如果为给定指针分配内存，则不要使用强制转换。

ptr = malloc(sizeof *ptr);

广告 1

第一种方法通过为给定类型分配内存来确保正确的大小，然后对其进行强制转换以确保将其分配给正确的指针。如果使用了不正确的 ptr 类型，则编译器将发出警告/错误。如果 ptr 的类型发生变化，那么编译器将指向代码需要重构的地方。

而且，第一种方法可以组合成一个类似于C++中new运算符的宏。

#define NEW(T) ((T*)malloc(sizeof(T)))
...
ptr = NEW(T);

此外，如果 ptr 是 void*，则此方法有效。

广告 2

第二种方法不关心类型，它通过从指针的类型中获取正确的大小来确保正确的大小。这种方法的主要优点是，只要 ptr 的类型发生变化，就会自动调整存储大小。它可以在重构时节省一些时间（或错误）。

缺点是如果 ptr 是 void* 该方法不起作用，但它可能被认为是一件好事。并且它不适用于 C++，因此不应在 C++ 程序将使用的头文件中的内联函数中使用它。

就个人而言，我更喜欢第二种选择。

---

对我来说，这里的带回家和结论是完全没有必要在 C 中强制转换 malloc，但是如果你强制转换，它不会影响 malloc，因为 malloc 仍会为你分配你请求的祝福内存空间。另一个带回家的是人们进行强制转换的原因或原因之一，这是为了使他们能够用 C 或 C++ 编译相同的程序。

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

---