home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!mips!carbon!news.cs.indiana.edu!syscon!gator!fang!att!allegra!alice!ark
- From: ark@alice.att.com (Andrew Koenig)
- Newsgroups: comp.lang.c++
- Subject: Re: Proposal: auto T&
- Message-ID: <23508@alice.att.com>
- Date: 21 Aug 92 02:07:14 GMT
- Article-I.D.: alice.23508
- References: <1992Aug19.234913.622@tfs.com> <1992Aug20.171342.3589@sunb10.cs.uiuc.edu> <9223406.29682@mulga.cs.mu.OZ.AU> <1992Aug20.213417.5690@sunb10.cs.uiuc.edu>
- Reply-To: ark@alice.UUCP ()
- Organization: AT&T Bell Laboratories, Murray Hill NJ
- Lines: 30
-
- In article <1992Aug20.213417.5690@sunb10.cs.uiuc.edu> pjl@sparc10.cs.uiuc.edu (Paul Lucas) writes:
-
- > >> a = stringfunction( b ) + stringfunction( c );
-
- > >What do you mean by "it's not reentrant"? Why not?
-
- > *****> Because the "slot" allocated in the caller would first receive
- > the temporary generated by "stringfunction( b )" then it would
- > be clobbered by "stringfunction( c )" and clobbered yet again by
- > the temporary generated by operator+, assuming it also used this
- > proposed technique.
-
- Hardly likely. The compiler had better allocate different memory locations
- for stringfunction(b) and stringfunction(c) regardless of parallelism,
- because otherwise how is it going to have them both around to hand
- to operator+?
-
- > The problem with that is, what does the compiler do if a
- > function returning an auto& calls itself?
-
- No problem: each function allocates memory for the values returned
- by the functions it calls directly. That set is always known at
- compile time.
-
- Of course, that's no different from what happens now with functions
- that return ordinary objects when compiled with a compiler with just
- a tiny bit of optimization.
- --
- --Andrew Koenig
- ark@europa.att.com
-