Article View: comp.lang.c.moderated
Article #1984Re: returning multiple values in C
From: James Kanze US/ESC 60/3/141 #407...
Date: Thu, 15 Feb 1996 14:51
Date: Thu, 15 Feb 1996 14:51
49 lines
2719 bytes
2719 bytes
In article <4fp1jm$h53@solutions.solon.com> andrewhw@uoguelph.ca
(Andrew Hamilton-Wright) writes:
|> Herman Rubin (hrubin@stat.purdue.edu) was heard to say:
|> >In article <4fjndv$ore@solutions.solon.com>,
|> >HASDI RODZMANN HASHIM <hasdi@engin.umich.edu> wrote:
|> [ some deletia ]
|> >>ldiv_t ldiv(long numer, long denom)
|> >>Which returns two values, quot and rem. To actually use this,
|> >>long a,b,d,e;
|> >>ldiv_t c;
|> >>...
|> >>c = ldiv(a,b);
|> >>d = c.quot;
|> >>e = c.rem;
|> >>...
|> >>A good compiler will optimize c out of existence. I just wished
|> >>that I could do something perl can already do...
|> >How can the compiler optimize it out of existence? Functions
|> >do not return results that way; the only possible way to avoid
|> I agree that the compiler cannot (and should not!) optimize
|> 'c' away -- but it is free to do so with both 'd' and 'e'.
And why not `c'. On a machine with a lot of banalized registers (RISC
architecture), the convention could very well be for the function to
return the struct in two registers. Starting from that, it is not
unusual for the compiler to notice that it already had the values in
the registers in the following assignments, and use them instead of
reading the struct. From there, supposing that this is the only
reference to `c', any decent optimizer will notice that the assigned
values are never used, and suppress the assignment. At that point,
there is no reference left to `c', and the compiler can suppress it.
(Whether it actually does or not depends on how the compiler is
organized. I suspect that in many compilers, some of the above
optimizations will only take place in the peep-hole optimizer, when it
is generally too late to actually suppress the variable.)
--
James Kanze Tel.: (+33) 88 14 49 00 email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
-- A la recherche d'une activité dans une region francophone
Technical Details
Message-ID:
<4fvh99$e48@solutions.solon.com>Path:
arc1-ca.pugleaf.net!solon.com!not-for-mailReferences:
<4fa7gv$2te@solutions.solon.com> <4fcq4u$fkl@solutions.solon.com> <4feok9$4m4@solutions.solon.com> <4fjndv$ore@solutions.solon.com> <4fm9fi$53a@solutions.solon.com> <4fp1jm$h53@solutions.solon.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!solon.com!not-for-mail From: James Kanze US/ESC 60/3/141 #40763 <kanze@lts.sel.alcatel.de> Newsgroups: comp.lang.c.moderated Subject: Re: returning multiple values in C Date: 15 Feb 1996 08:51:21 -0600 Organization: Digital Solutions Sender: clc@solutions.solon.com Approved: clc@solutions.solon.com Message-ID: <4fvh99$e48@solutions.solon.com> References: <4fa7gv$2te@solutions.solon.com> <4fcq4u$fkl@solutions.solon.com> <4feok9$4m4@solutions.solon.com> <4fjndv$ore@solutions.solon.com> <4fm9fi$53a@solutions.solon.com> <4fp1jm$h53@solutions.solon.com> NNTP-Posting-Host: solutions.solon.com