dmc*_*kee 38
在每个处理器上以最自然的方式实现事物的自由.
我认为c特别是在与其他任何语言不同的架构上实现了一致的实现.遵循针对当前常见的高端通用CPU优化的ABI将需要在一些奇怪的机器上进行非自然的扭曲.
Ste*_*non 10
除了选择了ABI的平台之外,在每个平台上都向后兼容.
而不是所有平台的通用ABI(这将是灾难性的,因为它只对一个平台最佳).标准委员会可以说每个平台都符合特定的ABI.
但是:谁定义了它(通过门的第一个编译器？).在这种情况下,他们获得了过度的竞争优势.或者是一个经过5年编制的委员会(这将是另一个可怕的想法).
此外,它不会让编译器对新的优化策略进行进一步的研究,您将会遇到标准定义时可用的技巧.
C(或C++)语言规范定义了源语言.他们并不关心运行它的处理器(AC程序甚至可以被人类奴隶解释,但那将是不道德的并且不具有成本效益).
根据定义,ABI是关于目标系统的.它与处理器和系统(以及ABI之后的现有库)有关.
在过去,确实发生了一些处理器具有专有(即未公开的)规范(甚至它们的机器指令集不公开),并且它们具有非公共ABI,其后是编译器(或多或少地遵循语言标准) ).
定义编程语言不需要与定义ABI相同的技能集.
您甚至可以为现有处理器定义更新的ABI,但这需要大量工作(修补编译器,重新编译所有内容,包括C&C++标准库以及您需要的所有实用程序和库),因此通常无用.
在大多数平台上,执行速度会受到严重影响.因此,对于许多嵌入式平台使用C语言可能不再合理.标准机构可能对由与ABI不兼容的各种芯片的制造商带来的反垄断诉讼负责.
基本上，每个人都错过了实际上是DID定义标准ABI的C ++ 14提案之一。它是专门用于使用C ++子集的库的标准ABI。您定义“ ABI”代码的特定部分（如名称空间），并且需要符合子集。
不仅如此，它还由C ++专家THE Herb Stutter撰写，并着有“ Exceptional C ++”系列丛书。
该提议有许多原因导致便携式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等），OS和位（32/64）的组合。
因此，这里的目标实际上是使C ++代码（Visual Studio）能够与同一平台上的其他C ++代码（GCC，旧版Visual Studio等）对话。通用ABI的目标不是让手机库在Windows计算机上运行。
该提议未在C ++ 14中批准，但是已进入C ++ 17的“演进”阶段，以供进一步讨论/迭代。
因此，截至2017年1月，我的手指仍然交叉。