From -12799139138168823 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,c79715c6d9945c29 X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 1992-11-12 00:33:56 PST Newsgroups: comp.std.c++ Path: sparky!uunet!pipex!warwick!bham!bhamvx!mccauleyba From: mccauleyba@vax1.bham.ac.uk (Brian McCauley) Subject: Re: return values and destructors Sender: usenet@rs6000.bham.ac.uk (USENET News Service) Message-ID: <1992Nov12.132254.1@vax1.bham.ac.uk> Date: Thu, 12 Nov 1992 13:22:54 GMT Lines: 51 References: <1dsevkINNe8t@agate.berkeley.edu> Organization: University of Birmingham In article <1dsevkINNe8t@agate.berkeley.edu>, jbuck@forney.berkeley.edu (Joe Buck) writes: > In article vinoski@ch.apollo.hp.com (Stephen Vinoski) writes: >>"A return statement with an expression can be used only in functions >>returning a value; the value of the expression is returned to the >>caller of the function." >> >>Given the statement >> >> return foo; >> > > [ example deleted: it's designed so that the destructor of an auto > variable will alter foo's value. ] > > Your example is the kind of thing that I think language standards should > leave explicitly undefined; otherwise compiler vendors will have to > generate worse code just in case someone like you gets tricky. :-) > [...] >>Is this a cfront bug? > > Again, I don't think so. I'm not willing to pay the cost of the > extra copy operation that might be required were the committee to > force your example to work. It's simply not worth slowing down reasonable > C++ programs to have defined behavior on your unreasonable example (it is > cute, though)... I beg to differ I think that the behaviour of Cfront is a bug and that the statement in the ARM is unambiguous if a little opaque. The redundant copy will only be avoidable in cases where the return type is an inbuilt type and the overhead of evaluating this before calling destructors and storing it away somewhere is minimal. Also the return expression would have to not contain any class types or even function calls as any class operation even on a object that is not local may legitamately make use of local objects. (Consider a class that has a static `population' member that is the total number of objects currently existing. I agree the original example was contrived but I don't think it should break a good complier. Some compilers offer optimization switches with names like "assume no pointer aliasing" which allow them to make this sort of optimisation at the risk of miscompiling this sort of perverse example. I do not think a compiler should make unsafe optimisations unless the programmer has invited it to do so. -- \\ ( ) NO BULLSHIT! from BAM (Brian McCauley) . _\\__[oo .__/ \\ /\@ E-mail: B.A.McCauley@bham.ac.uk . l___\\ Fax: +44 21 625 2175 # ll l\\ Snail: 197 Harborne Lane, Birmingham, B29 6SS, UK ###LL LL\\ ICBM: 52.5N 1.9W