🚀 go-pugleaf

In article <34200001@orstcs.UUCP> nathan@orstcs.UUCP (nathan) writes:
>       In returning a structure, one assigns to
>fields of a local variable, then returns it.
>To avoid [exta copying], some sort of "self" structure is needed.
>I propose three alternatives:

>1.		.a = 1;
As you say, what do you call the whole structure?
Also, it uses an intriguing general syntax for
a very small purpose.

>2.	struct ab func() {
>		func.a = 1;
>		return func;	// type-checking resolves return value
>	}
Type checking does not resolve anything if there is a conversion
operator from (struct ab (*)()) to (struct ab)--not inconceivable.

>3.	struct ab func() {
>		this.a = 1; this.b = 2;
Confusing to have "this" be pointer or struct depending on usage?

>Clearly there are other alternatives.
How about something ugly, unmistakable, and specific:
4.		return.a = 1; return.b = 2; // and, subr(&return)

By the way, if the copying bothers you, you can use reference types
in new code.  E.g.:  struct ab& func() {....}

There's actually a deeper problem:  Values are returned not by
assignment but by initialization.  That's a big difference in C++.
So "subr(&return)" would pass a pointer to an uninitialized object
to subr(), and so on.  This is probably an unacceptible breach of
C++ data integrity rules.  So C++ syntax for getting at the
yet-to-be-returned structure is a bad idea.  But all those copying
steps mentioned are not a problem in C++.  This C code:
	temp.a = 1; temp.b = 2; return temp;
could be replaced by this C++ code:
	return ab(1, 2);
(assuming definition of ab::ab(,)) and the compiler is responsible
for making it efficient.

-- 
----------------------------------------------------------
John R. Rose, Thinking Machines Corporation, Cambridge, MA
245 First St., Cambridge, MA  02142  (617) 876-1111 X270
rose@think.arpa				ihnp4!think!rose