🚀 go-pugleaf

mfx@cs.tu-berlin.de (Markus Freericks) writes:

>In article <3vq5so$8td@wsrcom.wsr.ac.at> hjp@wsrdb.wsr.ac.at (Peter
>Holzer) writes:
>
>> You cannot return multiple values in C anyway, so this is moot. You

>Sure it is moot, but this discussion is about possible extensions to C,
>not about the current standard (the thread started out as an advocacy
>of named return parameters, and I noted that those were only worthwhile
>if multiple results were allowed).

Ok. I got somewhat confused by different threads with the same
subject line and didn't realize we were talking about multiple
return values here. In this case we need too give them names, and
having one named return parameter just falls out as a special case.

I don't see much value in multiple return values, though. You can't
use them in an expression but have to assign them immediately to 
variables. You can have the same effect by including out parameters
as described by Stephen Baynes (See below).

>> can return a structure and are free to initialize only some of its
>> fields. And you are also free to change or not change locations to
>> which pointers are passed to the function.

>Yup, but both solutions introduce inefficiencies, as they practically
>(*) forbid the compiler to use registers for passing back the results.

Passing pointers does (And it also prevents the compiler from putting
the variable which was `passed by reference' to the function in a 
register which is even worse.

Returning a structure does not have this problem. Many compilers return
small structures in registers, and nothing prevents a compiler from
passing part of a structure in a registers and the other via memory
if the structure gets too large. It might be tough to determine which
part should be put in a register, but you have the same problem with
multiple return values.

Returning a structure also has the advantage, that its members are
named. I can never remember the sequence of the return values of the
perl localtime function, for example.


In a different article, under a different subject, but on the same
topic Stephen Baynes wrote:

> Alternative syntax is to present these as out parameters. Here are two ideas:
> 
> Eg[1]:
> void f (z) out (a,b)
>         float a;
>         int b;
>         int z;
> {
>         a = 3.14159;
>         b = 0x5050;
> }
> main()
> {
>         int i,j;
>         f(4) out (i,j);
> }

This is probably easier to parse than the original proposal (although
I would prefer if we would stick to prototype syntax and not fall back
to K&R I function definitions), but it effectively turns around the
direction of the assignment. I am not sure I like that.

> Eg[2]:
> void f (z, out a, out b)
>         float a;
>         int b;
>         int z;
> {
>         a = 3.14159;
>         b = 0x5050;
> }
> main()
> {
>         int i,j;
>         f(4, i, j);
> }

I dislike this for a different reason. At the point of the call you
cannot see that i and j will be modified. Besides it would be more
in the spirit of C to use cryptic characters to denote the direction
of information flow. Thus I repeat a proposal I already posted a year
or two ago:

At the point of the call, I want to show whether a value is passed to
the function, received from the function, or both. For this purpose
I propose three new unary operators which can be used only in this
context:

< value		: value is passed to the function.
> l-value	: The l-value will be modified by the function.
<> l-value	: value of the l-value is passed to the function
		  which will then modify the l-value.

The < operator is of course entirely redundant and only provided for
consistency.

In declaring function parameters, the same operators are used. The
example above can be written as:

void f (int z, float >a, int >b)
{
        a = 3.14159;
        b = 0x5050;
}

int main(void)
{
        int i,j;
        f(4, >i, >j);
}

A more modern version of mktime would be declared as 

time_t mktime (struct tm <>tmval);

Whether this is implemented as call-by-reference of call-by-value-return
is implementation-defined and may depend on the type of the variable
passed.

This changes C very little (instead of * at the definition and & at the
call of a function which needs to modify a parameter you use > or
<>), but provides more information to the compiler what is really going
on, so that it can produce better code without worrying about aliasing.
We can even allow & at the call instead of > and <>. This would allow
us to change the definitions of many library functions without breaking
code (except programs which insist on declaring library functions for
themselves. But they usually get all the consts wrong (and a few types 
as well) and need a lot of #ifdefs anyway).

	hp
--
   _  | Peter Holzer | Systemadministrator WSR | hjp@wsr.ac.at
|_|_) |-------------------------------------------------------
| |   |  ...and it's finished!  It only has to be written.
__/   |         -- Karl Lehenbauer