VLA parameters with changeable dimensions
uunet!homxb.att.com!wilber
uunet!homxb.att.com!wilber
Sun Dec 29 13:22:00 PST 1991
Thomas Breuel writes:
>I think you are missing the point. You are not computing the size of anything
>when you pass "variable length arrays". In fact, the terminology that we have
>been using on this list is unnecessarily confusing.
>...
>What you are doing is to state how you want to access data that has been
>passed to you. It seems to me to be a perfectly natural generalization
>to give the user the option to use variables instead of constants for
>the factors used in the array index computation.
>
>So, any of what you propose is fine. Multidimensional array subscripting
>can be viewed as a shorthand for:
>
> a[i1][i2][i3] === base_pointer_a[i3+dim_a_2*(i2+dim_a_1*i1)]
>
>For statically allocated arrays, dim_a_n happen to be constants,
>but why not make them variables?
Yes, I was a bit confused. In
foo (int n, double a[n])
{
double b[n];
}
sizeof(b) = n * sizeof(double) but sizeof(a) = sizeof(double*). Despite the
similarity in the syntax, C uses the size information for `b' but not for `a'.
Still, I'd like to keep the rules for `a' and `b' as much alike as possible.
Since it doesn't make a lot of sense to change the dimensions for `b', I'd
prefer not have the dimensions of `a' be changeable.
>Computations really belong into function bodies. I think it is wrong
>and bad to spill computations into function interfaces.
Constant expressions are already allowed in static initializers that aren't in
function bodies, so allowing arbitrary expressions for dimensions in function
headers doesn't strike me as being such a terribly rude thing to do.
>In fact, is
>the following prototype compatible with the following definition?
>
> void f(T n,float a[p(n)]);
> void f(T n,float a[q(n)]) {...}
When a dimension of an array is variable I don't think anything should be put
inside the corresponding brackets in the prototype. E.g., the correct
prototype for f would be
void f(T n, float a[]);
Is there anything wrong with this?
>We'll probably compromise on something like RMS's latest proposal.
Yup.
Bob Wilber wilberahomxb.att.com
More information about the Numeric-interest
mailing list