Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!hao!hplabs!qantel!lll-lcc!vecpyr!amd!amdcad!decwrl!sun!wdl1!jbn
From: jbn@wdl1.UUCP
Newsgroups: net.lang.c++
Subject: Re: further C++ fix opportunities
Message-ID: <152@wdl1.UUCP>
Date: Fri, 14-Mar-86 16:57:29 EST
Article-I.D.: wdl1.152
Posted: Fri Mar 14 16:57:29 1986
Date-Received: Sun, 30-Mar-86 04:04:35 EST
Sender: notes@wdl1.UUCP
Organization: Ford Aerospace, Western Development Laboratories
Lines: 50
Nf-ID: #R:orstcs:874967196:wdl1:44000001:000:1640
Nf-From: wdl1!jbn    Feb 28 15:00:00 1986


      This can be done without any new syntax.  First,
the right way to handle function return values is to have the caller
provide the space for them, of course.  Even in stock C the caller
has enough information to do this, since the caller is supposed to
have a skeletal function definition available if the function returns
something other than an "int".  (If your function returns a long, for
example, you are supposed to have "long foo()" visible to the caller,
and if you don't, results on a 16-bit machine will probably be disappointing.)
So the caller has enough information to allocate the object at call time.
      A useful optimization by the caller avoids the copy.  The
caller should treat large returned values as arguments passed by address.
In other words, when the returned value is large, it should be treated
as an additional parameter to the function passed by address.
If the result is used in an expression, the caller will have to allocate
temporary space for it.  But if the result is simply used in a replacement,
as in
		struct ssstruct {
			int ff;
			char cc;
			};
		/*	function foo	*/
		struct ss foo(p)
		int p;
		{ ... }
		struct ssstruct ss;
		ss = foo(1);

the compiler should observe that the immediate use of the result is in an
assignment, and should generate code much as if the call were

		foo(1,&ss);

Of course, if the call looks like

		int x;
		x = foo(1).ff;

the compiler has to generate something like

		{	struct sstruct TEMPXXX1;
			foo(p1,&TEMPXXX1);
			x = TEMPXXX1.ff;
		}

But I suspect that the optimized case appears more often in practice than
the nonoptimized one.

				John Nagle