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