Re: why cant functions return arrays

"sanjay.vasudevan@[EMAIL PROTECTED]
" <sanjay.vasudevan@[EMAIL PROTECTED]
> writes:
> Keith Thompson wrote:
[...]
>> Assume that f is a function that returns an array of int.  Presumably
>> you'd want to be able to do something like this:
>>
>>     int arr[100];
>>     arr = f();
>>
>> What if f returns an array of 90 ints?  Or 200?  Do you reject it at
>> compile time?  If so, you have to decide when writing the f *exactly*
>> how many elements it's going to return; that's far less flexible than
>> C's current (admittedly unwieldy) mechanisms.  Or do you reject it
>> during execution?  If so, how?  Do you introduce an exception
>> mechanism?  Do you just say it's undefined behavior?  Or do you copy
>> just part of the array?
>
> The following code gives a type mismatch error:
> int a[90];
> int (*b)[100];
> b = &a;
>
> doesnt this mean that there exists a restriction on array address
> assignment based on size.

Yes.  int[90] and int[100] are two distinct types; that's the problem.

It's actually not that much of a problem in C as it currently exists,
because we have other ways of working with arrays of arbitrary length:
we typically work with a pointer to the first element and some
programmer-defined technique of tracking the length.  Which means that
it's entirely up to the programmer to make sure array lengths match
when they need to.

> so, we cud allow functions to return arrays(as a first-class type) of
> known size (althogh as u mentioned, this is quite restrictive) and
> allow assigning only to same size arrays.

Right, and IMHO it wouldn't be worth it, because it would be so
inflexible.

<OT>
In Ada, you can declare an array type that leaves the dimensions
unspecified.  By specifying the dimensions, you create a *subtype*.
All subtypes of the same type are compile-time compatible, but
operations are checked at run time.  The languages operations are
sufficiently powerful (including passing arbitrary arrays as
parameters with full type checking, returning arbitrary arrays from
functions, and a built-in array slicing operation) to make this
workable.  I don't believe something like this could be added to C
without altering the feel of the language.
</OT>

> of course "int f()[];"  neednt be allowed.
>
> and this treatment as a first-class type would break existing code.

Yes.

-- 
Keith Thompson (The_Other_Keith) <kst-u@[EMAIL PROTECTED]
>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"