🚀 go-pugleaf

In <DCL2LC.GBK@proteon.com>, jfw@proteon.com (John Woods) writes:
>mfinney@inmind.com writes:
>>In <3vg8l8$5sd@myst.plaza.ds.adp.com>, whm@news (Bill Morrison) writes:
>>>halasz@caip.rutgers.edu wrote:
>>T aFunction(...) aName
>>   {
>>   aName = ...some value...;
>>   ...
>>   return;
>>   ...
>>   return ...some other value...;
>>   }
>
>Now it's my turn to respectfully disagree.
>
>What a big steaming crock of sh*t.  (whoops, there goes "respectfully")
>
>Just WHAT does this add to the C language that is of value?  Hint:  looking
>like FORTRAN or PASCAL are *not* of value.

I have encountered this lack as a serious problem in generated code where I
had no way to know the return type, but needed a variable (to be used for
storing the return value) of that type.  Further, it quite possibly can allow the
compiler to generate more efficient code when returning large (non-register
size) objects.  Normally those objects are allocated storage in the calling
routine and then passed to the function in question via a "hidden" parameter.
Without explicitly naming the return value, it can be more difficult or impossible
for the compiler to perform the construction of the return value "in place".
That failure can lead to much less efficient code.  Therefore, I believe that
such an extension is very much in the "spirit" of C (and C++ for that matter)
and NOT a way of grafting FORTRAN into C.

And, you might be just a bit more polite.

Michael Lee Finney