Visual C++ 和 gcc 一样强大吗？

Posted 2023-02-17

【中文标题】Visual C++ 和 gcc 一样强大吗？

【英文标题】：Is Visual C++ as powerful as gcc?

【发布时间】：2010-06-24 06:35:27

【问题描述】：

我对强大的定义是自定义能力。

我熟悉gcc 我想试试 MSVC。所以，我在 msvc 中搜索 gcc 等效选项。我找不到很多。

控制类型的输出

Stop after the preprocessing stage; do not run the compiler proper.
gcc: -E
msvc: ???

Stop after the stage of compilation proper; do not assemble.
gcc: -S
msvc: ???

Compile or assemble the source files, but do not link.
gcc: -c
msvc:/c

对调试很有用

Print (on standard error output) the commands executed to run the stages of compilation.
gcc: -v
msvc: ???

Store the usual “temporary” intermediate files permanently;
gcc: -save-temps
msvc: ???

是否有某种 gcc msvc 编译器选项映射指南？ gcc Option Summary 在每个部分中列出的选项比 Compiler Options Listed by Category 多。 msvc 中缺少很多重要而有趣的东西。是我遗漏了什么还是 msvc 确实不如 gcc 强大。

【问题讨论】：

对于gcc -v 的情况，我的猜测是msvc 编译器对所有内容都只是普通的cl，并且它没有像gcc 那样具有单独的可执行二进制文件。

我不明白您如何将“更强大”等同于“更多命令行开关”。

@Timbo：编译器错误确实会发生，看起来像编译器错误的错误也会发生：能够诊断这些错误很有用。

作为定义提供，“更强大=更多命令行开关”对我来说是合理的：他/她的意思是，使用开关我可以改变编译器的行为；更多的开关，更多的可调参数，更多的灵活性，所以在编译器的用户手中更“强大”。当然，应该考虑以下几点：允许多个参数的单个开关；例如xyz 可以有 -E 和 -S... 其中 abc 可以有 /c=preprocess-only 和 /c=do-not-assemble 只是说...导致二对一切换...

@claws 我不知道我是否会称 gcc 强大，但它肯定很慢。所有这些额外的命令只会增加不必要的复杂性。从可用性的角度来看，msvc 更有意义并且更容易上手。如果有一件事我希望 gcc 有它正在编译的文件的一些状态，比如 msvc、borland、dmc 和其他编译器。不，我不是说-v，这太冗长了——只是一个它当前正在编译的简单文件名……它甚至没有。

【参考方案1】：

MSVC 是一个 IDE，gcc 只是一个编译器。从 gcc 的角度来看，CL（MSVC 编译器）可以完成您所描述的大部分步骤。 CL /? 提供帮助。

例如

对标准输出的预处理：

CL /E

编译不链接：

CL /c

生成程序集（但与 gcc 不同，这不会阻止编译）：

CL /Fa

CL 实际上只是一个编译器，如果您想查看 IDE 生成哪些用于编译和链接的命令，最简单的方法是查看 IDE 中某个项目的属性页的命令行部分。 CL 不调用单独的预处理器或汇编器，因此没有单独的命令可查看。

对于-save-temps，IDE 执行单独的编译和链接，因此无论如何都会保留目标文件。要保留预处理器输出和汇编器输出，您可以通过 IDE 启用 /P 和 /Fa。

gcc 和 CL 不同，但我不会说 MSVC 缺少“很多”东西，当然不是您要寻找的输出。

【参考方案2】：

对于 -E 的等效项，cl.exe 具有/P（它不会“在预处理阶段后停止”，而是将预处理器输出输出到文件，这在很大程度上是相同的）。

对于 -S，它有点模糊，因为“编译”和“组装”步骤发生在多个地方，具体取决于您指定的 其他 选项（例如，如果您有整个程序开启优化，则直到链接阶段才生成机器码）。

对于 -v，Visual C++ 与 GCC 不同。它直接在 cl.exe（和 link.exe）中执行编译的所有阶段，因此没有“执行的命令”可以显示。 -save-temps 也是如此：因为一切都直接发生在 cl.exe 和 link.exe 中，所以唯一的“临时”文件是 cl.exe 生成的 .obj 文件，并且它们总是被保存。

不过，GCC 归根结底是一个开源项目。这意味着任何想抓挠的人都可以添加他们喜欢的任何命令行选项，而阻力相对较小。对于Visual C++这种商业闭源产品，每一个选项都需要有商业案例、设计会议、测试计划等等。 Every new feature starts with minus 100 points.

【讨论】：

我怀疑每个想抓挠的人都可以添加一个命令行选项 - 它仍然是一个稳定的软件项目，维护人员需要避免在已经复杂的代码中产生不必要的复杂性。当然，由于可以在本地添加新选项，因此更有可能会进行一些奇怪的实验，结果证明是有用的 - 当然，这会降低包含的障碍。

@Eamon：这可能是真的。我的主要观点是，微软很难为只有一小部分用户会觉得有用的东西添加命令行开关，而对于 GCC 来说就没有那么多了。

【参考方案3】：

两个编译器都有大量的选项来修改……一切。我怀疑两者中都不存在的任何选项都是首先不值得做的事情的选项。大多数“普通”用户无论如何都找不到这些选项的用途。

如果您纯粹将可用选项的数量作为“功能”或“灵活性”的衡量标准，那么您可能会发现 gcc 是赢家，因为 gcc 可以处理 Windows 以外的许多平台，并且具有特定的您在 MSVC 中显然找不到的许多平台的选项。 gcc（嗯，gcc 工具链）还编译了很多 C 和 C++ 之外的语言；例如，我最近将它用于 Objective-C。

编辑：我和 Dean 一起质疑你的问题的有效性。是的，MSVC (cl) 具有与 gcc 的许多选项相当的选项，但是不，选项的数量并不真正意味着太多。

简而言之：除非您正在做一些非常特别的事情，否则您会发现 MSVC 在 Windows 平台上很容易“足够强大”，您可能不会错过任何 gcc 选项。

【讨论】：

我在这里只考虑 C/C++。即使我从图片中删除了其他语言，也会缺少更多的东西，比如不同版本的 C/C++ 标准。关于“任何一个都不存在的选项都是首先不值得做的事情的选项”。我在问题中指出的选项不是有用的吗？他们不值得做吗？

@claws：您在问题中指出的选项是有用的，其他答案指出了 cl.exe 等效项。不同版本的 C/C++ 标准支持会很好。但是来吧，相当多的 gcc 旋钮和口哨是粗鲁的。你最后一次和-fschedule-insns2一起玩是什么时候？