Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!whuxl!whuxlm!akgua!gatech!seismo!cmcl2!phri!delftcc!sam
From: sam@delftcc.UUCP
Newsgroups: net.lang.c++,net.lang.c
Subject: Re: further C++ fix opportunities
Message-ID: <129@delftcc.UUCP>
Date: Fri, 28-Feb-86 09:46:23 EST
Article-I.D.: delftcc.129
Posted: Fri Feb 28 09:46:23 1986
Date-Received: Fri, 7-Mar-86 03:58:31 EST
References: <34200001@orstcs.UUCP>
Organization: Delft Consulting Corp., New York
Lines: 30
Xref: watmath net.lang.c++:55 net.lang.c:8067
Summary: C++ can't affect code generation, and a few minor points

In article <34200001@orstcs.UUCP>, nathan@orstcs.UUCP (nathan) writes:
> The "pcc" method [for returning structures] is no longer necessary.
> Now that each routine's type is known, space may be allocated for
> before the call.  (Is it?)

Every routine's return type is supposed to be known in regular C, and
indeed, several C compilers (including some PCC-based ones) handle
structure returns the way you suggest.

In any case, as I understand it, C++ is implemented as an extra
pass which outputs C code (PCC intermediate code on some machines?),
and it can't affect the function calling sequence or any other part of
code generation.  Even if it could, you want to keep the calling
sequences of C and C++ the same.

> Another problem, already present, now
> becomes evident.  In returning a structure, one assigns to fields of a
> local variable, then returns it.  This is copied into the return-value
> structure (whether on the stack, or elsewhere), after which the caller
> either copies it again or uses one field.  This extra copying seems
> unnecessary.  To avoid it, some sort of "self" structure is needed.

An good optimizer should eliminate the local variable-to-return value
copy.  Question: are there any that do?

----
Sam Kendall			     allegra \
Delft Consulting Corp.		seismo!cmcl2  ! delftcc!sam
+1 212 243-8700			       ihnp4 /
ARPA: delftcc!sam@nyu.ARPA