C/C++ 能做什么？ “失去”他们是否定义了标准 ABI？
标题说明了一切。我专门谈论 C/C++，因为两者都认为这是“实现问题”。我认为，定义一个标准接口可以轻松地在其上构建模块系统，以及许多其他好处。
如果 C/C++ 定义了标准 ABI，它们会“失去”什么？
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
在每个处理器上以最自然的方式实现事物的自由。
我认为，与任何其他语言相比，c 尤其在更多不同的体系结构上具有一致的实现。遵守针对当前常见、高端、通用 CPU 进行优化的 ABI 将需要在一些更奇怪的机器上进行不自然的扭曲。
The freedom to implement things in the most natural way on each processor.
I imagine that c in particular has conforming implementations on more different architectures than any other language. Abiding by a ABI optimized for the currently common, high-end, general-purpose CPUs would require unnatural contortions on some the odder machines out there.
除选择 ABI 的平台外，每个平台都向后兼容。
Backwards compatibility on every platform except for the one whose ABI was chosen.
基本上，每个人都忽略了 C++14 提案之一实际上确实定义了标准 ABI。它是专门针对使用 C++ 子集的库的标准 ABI。您定义“ABI”代码的特定部分（如命名空间），并且它需要符合子集。
不仅如此，它的作者是 C++ 专家、“Exceptional C++”系列丛书的作者 THE Herb Stutter。
该提案探讨了便携式 ABI 困难的多种原因，以及新颖的解决方案。
https://isocpp.org/blog/2014/05/n4028
http://www.open-std.org/jtc1/sc22 /wg21/docs/papers/2014/n4028.pdf
请注意，他将“目标平台”定义为 CPU 架构（x64、x86、ARM 等）、操作系统和位数（32/64 ）。
因此，这里的目标实际上是让 C++ 代码 (Visual Studio) 能够与同一平台上的其他 C++ 代码（GCC、旧版 Visual Studio 等）进行通信。让手机库在 Windows 计算机上运行的通用 ABI 的目标并不是这样。
该提案并未在 C++14 中获得批准，但是，它被移至 C++17 的“演进”阶段以进行进一步讨论/迭代。
https://www .ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/c_14_is_ratified_the_view_from_the_june_2014_c_standard_meeting?lang=en
因此，截至 2017 年 1 月，我的手指仍然交叉。
Basically, everyone missed that one of the C++14 proposals actually DID define a standard ABI. It was a standard ABI specifically for libraries that used a subset of C++. You define specific sections of "ABI" code (like a namespace) and it's required to conform to the subset.
Not only that, it was written by THE Herb Stutter, C++ expert and author the "Exceptional C++" book series.
The proposal goes into many reasons why a portable ABI is difficult, as well as novel solutions.
https://isocpp.org/blog/2014/05/n4028
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4028.pdf
Note that he defines a "target platform" to be a combination of CPU architecture (x64, x86, ARM, etc), OS, and bitness (32/64).
So the goal here, is actually having C++ code (Visual Studio) be able to talk to other C++ code (GCC, older Visual Studio, etc) on the same platform. It's not a goal of a universal ABI that lets cellphones libraries run on your Windows machine.
This proposal was NOT ratified in C++14, however, it was moved into the "Evolution" phase of C++17 for further discussion/iteration.
https://www.ibm.com/developerworks/community/blogs/5894415f-be62-4bc0-81c5-3956e82276f3/entry/c_14_is_ratified_the_view_from_the_june_2014_c_standard_meeting?lang=en
So as of January 2017, my fingers remain crossed.
而不是适用于所有平台的通用 ABI（这将是灾难性的，因为它只适用于一个平台）。标准委员会可以说每个平台都将符合特定的 ABI。
但是：谁定义了它（第一个通过门的编译器？）。在这种情况下，他们获得了过度的竞争优势。或者是经过 5 年编译器的委员会（这将是另一个可怕的想法）。
此外，它也不允许编译器进一步研究新的优化策略，您将陷入定义标准时可用的技巧中。
Rather than a generic ABI for all platforms (which would be disastrous as it would only be optimal for only one platform). The standard's committee could say that each platform will conform to a specific ABI.
But: Who defines it (the first compiler through the door?). In which case they get an excessive competitive advantage. Or a committee after 5 years of compilers (which would be another horrible idea).
Also it does not give the compiler leaway to do further research into new optimization strategies, you would be stuck with the tricks available at the point where the standard was defined.
C（或C++）语言规范定义了源语言。他们不关心运行它的处理器（AC 程序甚至可以由人类奴隶来解释，但这将是不道德的且不具有成本效益）。
根据定义，ABI 是关于目标系统的一些东西。它与处理器和系统（以及遵循ABI的现有库）有关。
在过去，确实发生过一些处理器具有专有（即未公开）规范（甚至它们的机器指令集不是公开的），并且它们具有非公开的 ABI，其后是编译器（或多或少尊重语言标准） ）。
定义编程语言不需要与定义 ABI 相同的技能。
您甚至可以为现有处理器定义更新的 ABI，但这需要大量工作（修补编译器、重新编译所有内容，包括 C 和 C++ 标准库以及您需要的所有实用程序和库），因此通常没用。
The C (or C++) language specifications define the source language. They don't care about the processor running it (A C program could even be interpreted by a human slave, but that would be unethical and not cost-effective).
The ABI is by definition something about the target system. It is related to the processor and the system (and the existing libraries following the ABI).
In the past, it did happen that some processors had proprietary (i.e. undisclosed) specification (even their machine instruction set was not public), and they had a non-public ABI which was followed by a compiler (respecting more or less the language standard).
Defining a programming language don't require the same skill sets as defining the ABI.
You could even define a newer ABI for an existing processor, but that requires a lot of work (patching the compiler, recompiling every thing, including C & C++ standard libraries and all utilities and libraries that you need) so is generally useless.
在大多数平台上，执行速度都会受到严重影响。如此之多以至于在许多嵌入式平台上使用 C 语言可能不再合理。标准机构可能会对与 ABI 不兼容的各种芯片制造商提起的反垄断诉讼负责。
Execution speed would suffer drastically on a majority of platforms. So much so that it would likely no longer be reasonable to use the C language for a number of embedded platforms. The standards body could be liable for an antitrust suit brought by the makers of the various chips not compatible with the ABI.
嗯，不会有一个标准 ABI，而是大约 1000 个。对于操作系统和处理器架构的每一种组合，您都需要一个。
最初，不会有任何损失。但最终，有人会发现一些可怕的错误，他们要么修复它，破坏 ABI，要么留下它，导致问题。
我觉得现在的情况是好的。任何操作系统都可以自由地为自己定义 ABI（他们确实这样做了），这是有道理的。定义其 ABI 应该是操作系统的工作，而不是 C/C++ 标准。
Well, there wouldn't be one standard ABI, but about 1000. You would need one for every combination of OS and processor architecture.
Initially, nothing would be lost. But eventually, somebody would find some horrible bug and they would either fix it, breaking the ABI, or leave it, causing problems.
I think that the situation right now is fine. Any OS is free to define an ABI for itself (and they do), which makes sense. It should be the job of the OS to define its ABI, not the C/C++ standard.
C 始终有一个标准 ABI，甚至是用于任何最标准 ABI 的 ABI（我的意思是，当不同的语言或系统必须相互绑定时，C ABI 是首选的 ABI）。 C ABI 是其他 ABI 的常见 ABI。尽管 C++ 是基于 C 的扩展，但它更加复杂，事实上，C++ 的标准 ABI 更具挑战性，并且可能会给 C++ 编译器自己实现目标机器代码的自由度带来问题。然而，它似乎实际上有一个标准的 ABI；请参阅安腾 C++ ABI。
因此，问题可能不是“他们会失去什么？”，而是“他们失去了什么？” （如果他们真的失去了一些东西）。
旁注：需要记住，ABI 始终依赖于架构和操作系统。因此，如果“标准 ABI”的含义是“跨架构和平台的标准”，那么除了通信协议之外，可能永远不会存在或存在这样的东西。
C always had a standard ABI, which is even the one used for any most standard ABI (I mean, the C ABI is the ABI of choice, when different languages or systems has to bind to each others). The C ABI is kind of common ABI of others ABIs. C++ is more complex although extending and thus based on C, and indeed, a standard ABI for C++ is more challenging and may present issues to the freedom a C++ compiler have for its own implementation of the target machine code. However, it seems to actually have a standard ABI; see Itanium C++ ABI.
So the question may not be that much “what could they loose?”, but rather “what do they loose?” (if ever they really loose something).
Side note: needed to keep in mind ABIs are always architecture and OS dependant. So if what was meant by “Standard ABI” is “standard across architectures and platforms”, then there may never has been or be such thing, but communication protocols.