jsdy@SEISMO.ARPA (01/11/85)
> foo(array, rows, cols) > int array[rows][cols], rows, cols; If this does get implemented, then I think you'd have to enforce a restriction that 'rows' and 'cols' be "const" within the routine. (I'll have to go look at the Standard to see whether the concept of "const auto" occurs.) Then, computations can take place, albeit (as everyone agrees) a much more complex compiler to handle this. As dgary says, evaluation of the "sizeof" operator would have to be deferred (at least in this case) until runtime. This may upset people who have come to trust that a sizeof is a runtime constant. I will re-phrase my major concern with this. This will either produce semantics inconsistent with those for the syntactically similar constant-sized array arguments, or the latter must be changed, thus breaking many programs. Joe Yao (UUCP!seismo!hadron!jsdy / hadron!jsdy@seismo.ARPA)
jsdy@SEISMO.ARPA (01/15/85)
> I wish you would explain how the semantics of > foo( int array[rows][cols], int rows, int cols ); > would be inconsistent with those already in effect for > constant-sized array arguments. I don't see this at all. Hmmm. If I said t h a t , then I must be working later than I thought. I believe I confusing two things in one message. Passing arrays by value (entirely on the stack) is inconsistent with the current semantics. This is what one person had suggested. The current semantics is that all arrays are passed by reference (pointer). Passing a pointer to an array, after passing one or more of its dimensions, seems to me to be consistent, but needs a lot more work on the part of the compiler. Which is fine with me, but I don't have time to do it this week (month, ...). Anybody? Remember that this means the dimensions must be either squirreled away or declared 'const'. Also, there are lots of chances now for people to break programs by changing array sizes one place but not another ... but that's nothing gnew, I guess. We're not going to check array sizes, here. Joe Yao (UUCP!seismo!hadron!jsdy / hadron!jsdy@seismo.ARPA)