我想知道您可以传递给函数的参数数量是否有限制。
我只是想知道，因为我必须在我的工作中保留5个以上参数的功能。
在nbArguments中是否存在关键性阈值，谈论性能，还是线性？
答案 0 :(得分：8)
考虑到C varargs（通常）以与其他论据相同的方式机械传递，似乎你正在转向主观领域。
在大多数ABI下，前几个参数放在CPU寄存器中。多少取决于架构寄存器的数量;它可能从2到10不等。在C ++中，通常会完全省略空类（例如重载调度标记）。将数据加载到寄存器中通常是“便宜的免费”。
在寄存器之后，参数被复制到堆栈中。你可以说这需要线性时间，但这些操作并非都是平等的。如果您要在相同的参数上调用一系列函数，您可以考虑将它们一起打包为struct并通过引用传递它。
要从字面上回答您的问题，参数的最大数量是实现定义的数量，这意味着ISO标准需要您的编译器手册来记录它。 C ++标准还建议（附件B）没有任何实现不会超过 256个参数，这应该是足够的任何人。 C要求（§5.2.4.1）支持至少 127个参数，尽管该要求在规范上是合格的，例如将其弱化为仅推荐。
答案 1 :(得分：8)
C和C ++标准都没有对调用函数时必须能够传递的参数/参数的数量提出绝对要求，但C标准建议实现应该支持至少127个参数/参数（第5.2节） .4.1 / 1），C ++标准表明它应该支持至少256个参数/参数（§B/ 2）。
C标准的准确措辞是：
实现应能够翻译和执行至少一个程序 包含以下每个限制的至少一个实例。
因此，必须成功翻译一个这样的函数，但不能保证如果你的代码尝试这样做，编译将会成功（但在现代实现中可能会这样）。
C ++标准甚至没有走得那么远，只能说：
建议将每个数量后面的括号内的数字作为该数量的最小值。但是，这些数量仅是指导原则，不能确定合规性。
至于什么是可取的：这取决于。一些函数（特别是使用可变参数/可变参数模板的函数）接受任意数量的（或多或少）任意类型的参数。在这种情况下，传递相对大量的参数可能是有意义的，因为每个参数或多或少独立于其他参数（例如，打印项目列表）。
当参数更加......相互依赖时，所以你不只是传递一个列表或那个订单上的东西，我同意这个数字应该更加有限。在C中，我已经看到一些高达10左右而不是非常笨拙，但这绝对是开始在极限情况下推动极限。在C ++中，将相关项聚合成struct或class通常更容易（也更常见）我无法想象许多参数，除非它在C兼容层或其他内容中在那个订单上，更加......结构化的方法可能会迫使用户做更多的工作。
最后，它归结为：你要么必须传递较小数量的单独较大的项目，要么将函数调用分解为多个调用，将少量参数传递给每个
后者可能倾向于导致有状态接口，这基本上会以或多或少的固定顺序强制执行多个调用。您已经降低了单个调用的复杂性，但可能很少或根本不会减少代码的整体复杂性。
另一方面，大量参数可能意味着你已经真正定义了执行大量相关任务的功能，而不是一个明确定义的任务。在这种情况下，为各个函数找到更具体的任务来执行，并传递每个函数所需的一小组参数，这可能会降低代码的整体复杂性。
答案 2 :(得分：4)
它并不是很脏，有时你可以避免使用4个以上的参数，同时保持稳定性和效率。如果可能的话，它应该被最小化以便清楚（可能通过使用结构），特别是如果你认为某些功能正在成为一个神构造（运行大部分程序的功能，为了稳定性应该避免它们）。如果是这种情况，那么采用大量参数的函数就是这种结构的非常好的指标。