理论上可以在 c++ 函数中作为参数传递多少个参数？答案

【问题标题】：How many arguments can theoretically be passed as parameters in c++ functions?理论上可以在 c++ 函数中作为参数传递多少个参数？
【发布时间】：2014-07-09 05:51:52
【问题描述】：

我想知道您可以传递给函数的参数数量是否有限制。

我只是想知道，因为我必须在我的工作中维护 5+ 参数的函数。

nbArguments 中是否有一个关键阈值，谈论性能，还是线性的？

【问题讨论】：

我认为这不是性能问题，而是可读性问题。 Code Complete 建议的神奇数字是7，因为人脑很难同时记住超过 7 个单位的信息。
越少越好，保持凝聚力。
理论上，限制是堆栈大小（假设有一个堆栈并且参数被推到那里）。除此之外，是的，超过 4 个开始变得有点混乱，这强烈暗示代码需要一些重构。当然，也有一些例外。我想这里的性能不是问题，你很快就会被代码维护问题而不是性能问题打败。
你到底在问什么？您的标题暗示了一件事，而问题的主体则是另一件事。
没有一成不变的幻数...如果您能找到一种方法来更好地考虑代码的可读性/可维护性/性能或其他对您很重要的东西，然后做所以。诸如在单个结构中传递多个值、传递容器（数组、映射、可能的变体）等技术可能会有所帮助....

标签： c++ c function arguments

【解决方案1】：

C 和 C++ 标准都没有绝对要求调用函数时必须能够传递的参数/参数的数量，但 C 标准建议实现应支持至少 127 个参数/参数（第 5.2 节） .4.1/1)，而 C++ 标准建议它应该支持至少 256 个参数/参数 (§B/2)。

C 标准的准确措辞是：

实现应该能够翻译和执行至少一个程序包含以下每一项限制的至少一个实例。

因此，必须成功翻译一个这样的函数，但不能保证如果您的代码尝试这样做，编译会成功（但在现代实现中可能会成功）。 p>

C++ 标准甚至没有走那么远，只是这么说：

建议将每个数量后面的括号中的数字作为该数量的最小值。但是，这些数量仅供参考，并不能确定合规性。

至于什么是可取的：这取决于。一些函数（尤其是那些使用可变参数/可变模板的函数）接受任意数量的（或多或少）任意类型的参数。在这种情况下，传递相对大量的参数是有意义的，因为每个参数都或多或少独立于其他参数（例如，打印项目列表）。

当参数更...相互依赖时，因此您不只是按该顺序传递列表或其他内容，我同意该数字应该受到更多限制。在 C 语言中，我看到有一些可以达到 10 左右，而不会非常笨拙，但这肯定会开始突破极限，即使充其量也是如此。在 C++ 中，将相关项目聚合到 struct 或 class 中通常更容易（也更常见），除非它位于 C 兼容层或按顺序排列的其他东西中，否则我无法想象有这么多参数，更...结构化的方法可能会迫使用户做更多的工作。

最后，它归结为：您要么必须传递较少数量的单独较大的项目，要么将函数调用分解为多个调用，将较少数量的参数传递给每个。

后者可能会趋向于一个有状态的接口，这基本上会强制以或多或少固定的顺序进行一些调用。您已经降低了单个调用的复杂性，但很容易在降低代码的整体复杂性方面做得很少或根本没有做任何事情。

另一方面，大量参数可能意味着您确实定义了执行大量相关任务的函数，而不是一个明确定义的任务。在这种情况下，为各个函数找到更具体的任务来执行，并传递每个函数所需的一组较小的参数，可以很好地降低代码的整体复杂性。

【讨论】：

好的，一开始我区分了经典参数和可变参数，但它没有意义。
强制性 Alan Perlis 引用：“如果您有一个包含十个参数的程序，您可能会遗漏一些。”

【解决方案2】：

考虑到 C 可变参数（通常）以与其他参数相同的方式机械传递，看来您正在转向主观领域。

前几个参数放在 CPU 寄存器中，在大多数 ABI 下。多少取决于架构寄存器的数量；它可能从二到十不等。在 C++ 中，空类（例如重载调度标签）通常被完全省略。将数据加载到寄存器通常是“便宜又免费”。

在寄存器之后，参数被复制到堆栈中。你可以说这需要线性时间，但这些操作并非都是平等的。如果您要在相同的参数上调用一系列函数，您可以考虑将它们打包为 struct 并通过引用传递。

从字面上回答您的问题，参数的最大数量是实现定义的数量，这意味着 ISO 标准要求您的编译器手册对其进行记录。 C++ 标准还建议（附件 B），任何实现都不要拒绝少于 256 个参数，这对于任何人来说都应该足够了。 C 要求（第 5.2.4.1 节）至少支持 127 个参数，尽管该要求在规范上是合格的，例如将其弱化为仅推荐。

【讨论】：

【解决方案3】：

它并不是很脏，有时你无法避免使用 4+ 参数同时保持稳定性和效率。如果可能的话，为了清楚起见应该将其最小化（也许通过使用结构），特别是如果您认为某些函数正在成为上帝构造（运行大部分程序的函数，为了稳定性应该避免它们）。如果是这种情况，接受更多参数的函数是此类构造的很好指标。

【讨论】：