home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12597 < prev    next >
Encoding:
Text File  |  1992-08-19  |  1.7 KB  |  39 lines
  1. Newsgroups: comp.lang.c++
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!elroy.jpl.nasa.gov!ames!agate!tfs.com!tfs.com!eric
  3. From: eric@tfs.com (Eric Smith)
  4. Subject: Proposal: auto T&
  5. Message-ID: <1992Aug19.234913.622@tfs.com>
  6. Organization: TFS
  7. Date: Wed, 19 Aug 1992 23:49:13 GMT
  8. Lines: 29
  9.  
  10.  
  11. Much recent discussion about destruction of temporaries suggests a
  12. better way to solve the whole problem, and to allow returning references
  13. to temporaries from functions.
  14.  
  15. auto String& stringfunction(const String& input)
  16. {
  17.    // Calculate/create a new temporary or named automatic String
  18.    // and return a reference to it.
  19. }
  20.  
  21. The "auto" in the function return value type tells the compiler to allocate
  22. the space for that automatic in the stack frame of the caller, instead of
  23. the stack frame of the called function.
  24.  
  25. The compiler can also do the same kind of thing implicitly within a function.
  26. That is, allocate the space for each temporary in the outermost stack frame
  27. containing references to it.  It doesn't need an explicit "auto" for that
  28. because it can derive it during the compile.
  29.  
  30. Costs/benefits:  The compiler needs to do a little more work to handle auto T& 
  31. and the auto might need to be accessed via a pointer because it might not be
  32. possible for the compiler to know its stack offset at compile time.  The
  33. benefits to the programmer might be a lot bigger than the obvious benefits
  34. seem at first.  Beginning C++ programmers almost aways complain about the
  35. problems caused by lack of this functionality, which they almost always
  36. intuitively assume without even thinking about the implications.  A lot of
  37. function interfaces would become much neater.  A lot of the complaints about
  38. lack of garbage collection are really motivated by lack of this functionality.
  39.