Path: utzoo!utgpu!watmath!iuvax!rutgers!columbia!read.columbia.edu!kearns
From: kearns@read.columbia.edu (Steve Kearns)
Newsgroups: comp.lang.c++
Subject: Re: named return values
Message-ID: <6444@columbia.edu>
Date: 9 Aug 89 02:14:05 GMT
References: <1826@cmx.npac.syr.edu> <26302@shemp.CS.UCLA.EDU>
Reply-To: kearns@cs.columbia.edu
Organization: Columbia University Department of Computer Science
Lines: 34


I am in favor of named return values; however....

much of their use can be avoided, I have found.  Many of the libg++
library classes attempt to simulate "value" semantics.  For example,
you might be able to use a matrix class by saying:

matrix m1, m2, m3;
...
m1 = m1 + 2*m2 + m3;

While this is very nice in theory, in practice it can lead to horrible
performance because of the various temporary matrices that are created.  

I think the best near term solution to this problem is to allow the
programmer to explicitly control memory use.  The way this is done is
by declaring destructive plus and times operations.  m1.plus(m2) is a
routine which modifies m1 so that (new)m1 = (old)m1+m2.  Then the
above program could be rewritten:

m1.plus(matrix(m2).times(2)).plus(m3)

(assume that matrix(m2) is a constructor returning a matrix equal to
m2.)  Admittedly, the syntax is much less readable.  On the other
hand, it gives the programmer the chance to optimize his expressions
and significantly reduce the number of large temporaries.  It is also
more "honest":  matrices are NOT good candidates for having value semantics
because their copying time is large.  

By writing in this style when appropriate, most uses of named return values
go away.

-steve
(kearns@cs.columbia.edu)