home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / lang / cplus / 12750 < prev    next >
Encoding:
Internet Message Format  |  1992-08-21  |  3.6 KB

  1. Path: sparky!uunet!elroy.jpl.nasa.gov!usc!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  2. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: destruction of temporaries
  5. Message-ID: <TMB.92Aug22001131@arolla.idiap.ch>
  6. Date: 22 Aug 92 04:11:31 GMT
  7. References: <BszApE.49v@world.std.com> <1992Aug17.073500.24115@ericsson.se>
  8.     <23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com>
  9.     <TMB.92Aug20142610@arolla.idiap.ch> <23507@alice.att.com>
  10.     <TMB.92Aug21142555@arolla.idiap.ch> <9223502.26462@mulga.cs.mu.OZ.
  11. Sender: news@ai.mit.edu
  12. Reply-To: tmb@idiap.ch
  13. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  14.     Perceptive)
  15. Lines: 77
  16. In-reply-to: fjh@mundil.cs.mu.OZ.AU's message of 21 Aug 92 16:58:13 GMT
  17.  
  18.  
  19.    tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  20.  
  21.    >In article <23507@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
  22.    >
  23.    >   The trouble comes with expressions like
  24.    >
  25.    >       foo().bar().baz()
  26.    >
  27.    >   where bar returns *this. If an implementation is allowed to delete
  28.    >   the result of foo() before calling baz, the roof can cave in even
  29.    >   if your defensive rules are followed.
  30.    >
  31.    >Read my paragraph again. I explicitly stated you shouldn't return a
  32.    >reference to "*this".
  33.  
  34.    What about
  35.  
  36.        cout << "Hello World" << endl;
  37.  
  38.    Does this mean that we have to go back to printf?
  39.  
  40. No, it doesn't mean that. Perhaps I should have been more explicit.
  41.  
  42. You want to avoid getting dangling references to temporaries.
  43. Generally, the safest way is not to return pointers/references to
  44. arguments of (member) functions.
  45.  
  46. Tradition and syntax suggest that for a few functions you end up
  47. wanting to do this anyway. Simply try to avoid making a habit of
  48. introducing new functions like this. If you do write them, don't ever
  49. use them with temporaries.
  50.  
  51. Hence, it's OK to write:
  52.  
  53.     a = s;
  54.     cout << "Hello World\n";
  55.  
  56. However, you should worry when you see code like the following
  57. (fortunately, cases like this are syntactically pretty obvious).  You
  58. should worry because you are (hopefully) very aware of the fact that
  59. operator= and operator<< return references:
  60.  
  61.     (x+y) = s;
  62.     make_stream(1) << "Hello World\n";
  63.  
  64. If you do want to write something like this (which I have never wanted
  65. to), say instead:
  66.  
  67.     String temp = x+y;
  68.     temp = s;
  69.  
  70.     ostream stream = make_stream(1);
  71.     stream << "Hello World\n";
  72.  
  73. Incidentally, I believe, in principle, "operator<<" could have been
  74. defined to return an "ostream" with appropriate semantics (rather than
  75. an "ostream&"), so that this wouldn't even have been an issue. But
  76. given that "ostream" is almost never a temporary, and that everybody
  77. _knows_ what operator<< returns, the current rule is probably OK
  78. (and more efficient).
  79.  
  80. All of this is a matter of style, taste, and the particular kinds of
  81. applications you happen to write frequently (I write graphics,
  82. numerical, image processing, user interface, and string code in C++,
  83. so I think my applications are pretty mainstream). All I can say is
  84. that (1) I have not found dangling references to temporaries to be a
  85. major problem (in fact, I had never even considered it to be an
  86. important issue before this discussion--I felt C++ was using the
  87. "obvious" rule within its limitations), (2) trying to make up for the
  88. inefficiencies resulting from late destruction of temporaries seems to
  89. me to be much harder than avoiding dangling references to temporaries,
  90. and (3) even if later destruction of temporaries were adopted, you
  91. still would have to be careful not to get dangling references at the
  92. block/function level--without GC, the problem will not go away.
  93.  
  94.                     Thomas.
  95.