c++ - 简单明了，我们为什么要使用 _stdcall？

Question

我在研究使用 C++ 制作游戏的状态时遇到了调用约定。

在之前的问题中有人说 MSDN 没有很好地解释 _stdcall - 我同意。

像 _stdcall 这样的调用约定的主要目的是什么？参数在堆栈中的放置顺序重要吗？它如何减少 X86 中的代码大小(如其他人所述)？

Answer 1

采用一些调用约定的原因很简单:以便调用者和被调用者就事情的工作方式达成一致。没有它，调用者在调用特定函数时不知道将参数放在哪里。

至于微软为何决定 _stdcall 的具体细节，这很大程度上是历史原因。在 MS-DOS 上，所有调用都是基于寄存器的，因此所有操作系统调用都需要汇编语言，或者对大多数高级语言的奇怪扩展。

当他们第一次做 Windows 时，他们使用 cdecl 调用约定，主要是因为这是编译器默认执行的操作。至少根据谣言，在他们准备发布 Windows 1.0 之前不久，他们转向了 Pascal 调用约定，因为它足够高效(除其他外)它允许 Windows 可以安装在更少的一张软盘上。不管精确细节如何，Pascal 调用约定确实使代码更小一些，因为被调用函数从堆栈中清除了参数，而不需要在调用函数的所有地方清除它们。对于从至少 2 个不同位置调用的任何函数，这就是胜利(如果它在其他任何地方都平局)。

然后他们开始研究 OS/2，并发明了另一种调用约定(系统调用)。

然后，当然是 Win32。从技术角度来看，syscall 并没有太多错误，但是(我猜)与 OS/2 相关的所有内容都被认为是有问题的，所以 syscall 必须取消。结果完全不同，足以证明一个新名称的合理性。公平地说，这有点夸张:他们确实添加了一个真正有用的补充:他们将参数的字节数编码到每个函数名称中，因此如果(例如)您为函数提供了错误的原型(prototype)，代码将不会'链接而不是以调用者和被调用者之间的不匹配结束，这可能会导致更严重的问题。

但在大多数情况下，它实际上又回到了原点:调用约定的确切细节并不那么重要，只要您不把它弄得一团糟即可。最重要的是调用者和被调用者就同一件事达成一致，因此如果编译器知道函数接受哪些参数，它就知道如何生成代码以正确地将这些参数传递给函数(同样，它们都同意如何处理堆栈清理等)