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)