home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / cplus / 17953 < prev    next >
Encoding:
Text File  |  1992-12-14  |  1.4 KB  |  33 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!microsoft!hexnut!jimad
  3. From: jimad@microsoft.com (Jim Adcock)
  4. Subject: Re: Complex Addition.
  5. Message-ID: <1992Dec14.211941.20150@microsoft.com>
  6. Date: 14 Dec 92 21:19:41 GMT
  7. Organization: Microsoft Corporation
  8. References: <1992Dec11.170849.18525@rs6000.bham.ac.uk> <Bz3ynn.A1w@cs.uiuc.edu>
  9. Lines: 22
  10.  
  11. In article <Bz3ynn.A1w@cs.uiuc.edu> pjl@cs.uiuc.edu (Paul Lucas) writes:
  12. |In <1992Dec11.170849.18525@rs6000.bham.ac.uk> pickerig@eee.bham.ac.uk (Guy Pickering) writes:
  13. |>inline complex operator+(complex a, complex b)
  14. |>{
  15. |>  return complex(a.re+b.re,a.im+b.im)
  16. |>}
  17. |
  18. |>Doesn't the complex object go out of scope?
  19. |
  20. |*****>    It's not in the scope of the function; it's in a temporary for
  21. |    the return-value of the function that gets destroyed sometime
  22. |    thereafter.
  23.  
  24. Nit disagreement.  I'd claim that the return expression must be in
  25. the scope of the function.  In this case the "complex(...)" must
  26. be the return expression and thus must be in scope of the function.
  27. Thus "complex(...)" creates an unnamed temporary object that is
  28. in scope.  Its *another* unnamed temporary inited from this unnamed
  29. temporary "that gets destroyed sometime thereafter."  Of course, the
  30. compiler typically can realize that two unnamed temporaries are
  31. unnecessary and optimize this down to one unnamed temporary, or mayne
  32. even zero unnamed temporaries depending on calling context...
  33.