home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12654 < prev    next >
Encoding:
Text File  |  1992-08-20  |  2.2 KB  |  53 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!usc!sdd.hp.com!ux1.cso.uiuc.edu!m.cs.uiuc.edu!sunb10.cs.uiuc.edu!sparc10.cs.uiuc.edu!pjl
  3. From: pjl@sparc10.cs.uiuc.edu (Paul Lucas)
  4. Subject: Re: Proposal: auto T&
  5. Message-ID: <1992Aug20.171342.3589@sunb10.cs.uiuc.edu>
  6. Sender: news@sunb10.cs.uiuc.edu
  7. Organization: University of Illinois at Urbana-Champaign
  8. References: <1992Aug19.234913.622@tfs.com>
  9. Date: Thu, 20 Aug 1992 17:13:42 GMT
  10. Lines: 41
  11.  
  12. In <1992Aug19.234913.622@tfs.com> eric@tfs.com (Eric Smith) writes:
  13.  
  14.  
  15. >Much recent discussion about destruction of temporaries suggests a
  16. >better way to solve the whole problem, and to allow returning references
  17. >to temporaries from functions.
  18.  
  19. >auto String& stringfunction(const String& input)
  20. >{
  21. >   // Calculate/create a new temporary or named automatic String
  22. >   // and return a reference to it.
  23. >}
  24.  
  25. >The "auto" in the function return value type tells the compiler to allocate
  26. >the space for that automatic in the stack frame of the caller, instead of
  27. >the stack frame of the called function.
  28.  
  29. *****>    It's not reentrant.
  30.  
  31.     String a, b, c;            // also assume + has been overloaded
  32.     // ...
  33.     a = stringfunction( b ) + stringfunction( c );
  34.  
  35. >The compiler can also do the same kind of thing implicitly within a function.
  36. >That is, allocate the space for each temporary in the outermost stack frame
  37. >containing references to it.  It doesn't need an explicit "auto" for that
  38. >because it can derive it during the compile.
  39.  
  40. >Costs/benefits:  The compiler needs to do a little more work to handle auto T& 
  41. >and the auto might need to be accessed via a pointer because it might not be
  42. >possible for the compiler to know its stack offset at compile time.  The
  43. >benefits to the programmer might be a lot bigger than the obvious benefits
  44. >seem at first.  Beginning C++ programmers almost aways complain about the
  45. >problems caused by lack of this functionality, which they almost always
  46. >intuitively assume without even thinking about the implications.  A lot of
  47. >function interfaces would become much neater.  A lot of the complaints about
  48. >lack of garbage collection are really motivated by lack of this functionality.
  49. -- 
  50.     - Paul J. Lucas                University of Illinois    
  51.       AT&T Bell Laboratories        at Urbana-Champaign
  52.       Naperville, IL            pjl@cs.uiuc.edu
  53.