home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!olivea!mintaka.lcs.mit.edu!ai-lab!life.ai.mit.edu!tmb
- From: tmb@arolla.idiap.ch (Thomas M. Breuel)
- Newsgroups: comp.lang.c++
- Subject: Re: destruction of temporaries
- Message-ID: <TMB.92Aug21142555@arolla.idiap.ch>
- Date: 21 Aug 92 18:25:55 GMT
- References: <BszApE.49v@world.std.com> <1992Aug17.073500.24115@ericsson.se>
- <23466@alice.att.com> <3920@starlab.UUCP> <23487@alice.att.com>
- <TMB.92Aug20142610@arolla.idiap.ch> <23507@alice.att.com>
- Sender: news@ai.mit.edu
- Reply-To: tmb@idiap.ch
- Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
- Perceptive)
- Lines: 29
- In-reply-to: ark@alice.att.com's message of 20 Aug 92 21:16:28 GMT
-
- In article <23507@alice.att.com> ark@alice.att.com (Andrew Koenig) writes:
-
- In article <TMB.92Aug20142610@arolla.idiap.ch> tmb@idiap.ch writes:
-
- > You can avoid unexpected behavior involving temporaries by programming
- > defensively. In particular, this means: do _not_ return a reference or
- > pointer to an explicit or implicit argument or its contents (*this,
- > call-by-value, call-by-reference). Furthermore, do _not_ define cast
- > operators to pointer types in your classes (instead, make them normal
- > member functions that you have to call explicitly).
-
- I wish life were that simple. The trouble comes with expressions like
-
- foo().bar().baz()
-
- where bar returns *this. If an implementation is allowed to delete
- the result of foo() before calling baz, the roof can cave in even
- if your defensive rules are followed.
-
- Read my paragraph again. I explicitly stated you shouldn't return a
- reference to "*this".
-
- That is enough to argue, at least for me, that the current rule of
- allowing temporaries to be destroyed as soon as they are fetched,
- is too liberal.
-
- All I can say is that I disagree.
-
- Thomas.
-