Re^4: Variable Parameters

[Eric A. Raymond]

chris at mimsy.umd.edu (Chris Torek) writes:

>In article <3387 at bacon.ptolemy.arc.nasa.gov> raymond at ptolemy.arc.nasa.gov
>(Eric A. Raymond) writes:
>>Difficult?  Expensive?  Not really, since at compile time each caller
>>knows how many arguments it is passed, right?  (Note: this is true
>>even if the function (i.e., called via a ptr) is unknown at compile-time.)

>Difficult: no.  Expensive: possibly, although varargs functions are
>relatively rare, so if this is done only for varargs functions, I would
>say `probably not'.  But:

Just passing the number of args for each function declared with "..."
is a very small overhead.  Even if we did it for all fn calls, how
much overhead is an extra parameter?  (Rhetorical Question ;-)

>C does not have values.  C has *typed* values.  You cannot ask or answer
>anything about a value without first knowing its type.  For instance,
>what value does the bit pattern 0x4120 represent?  Surprise, the answer
>is `2.5', because I meant `VAX single precision floating point'.  (If
>you had guessed 2.5, I would have said I meant an integer: 16772.)

OK.  But this is different than just getting the number of arguments.
I was just proprosing an extension.  There are many cases where one
knows the types of the arguments but not the number.  This does not
mean that the type of the args is fixed, but you would need a new
accessor function (and initially access each var in sequential order
so you know where each one starts on the stack).  This starts getting
a bit complicated.  I agree.

>Even solutions of the form `pass a string denoting number of arguments
>and type' can fall down, because there are complicated types that are
>hard to describe: for instance, unions containing structures, and vice
>versa.

Or you could pass a pair of parameters for each arg.  The first of
which corresponds to some ID (numeric) in a type hierarchy.  Of course
there would be all sorts of syntactic sugar to hide this from the
programmer.

When it comes down to it, we are talking about expressability and ease
of implementation over efficiency.  If this vararg style of fn calling
is in the minority, then there won't be much overhead.  Me thinks a
good compiler and syntax could solve most of this, though.

-- 
Eric A. Raymond  (raymond at ptolemy.arc.nasa.gov)
G7 C7 G7 G#7 G7 G+13 C7 GM7 Am7 Bm7 Bd7 Am7 C7 Do13 G7 C7 G7 D+13: Elmore James