C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  return value optimization and aliasing          C++Talk.NET Forum Index -> C++ language, library and standards View previous topic :: View next topic   Author Message Fernando Cacciola Guest Posted: Mon Feb 23, 2004 6:32 am    Post subject: return value optimization and aliasing Hi, Consider: struct point { point( int x_, int y_ ) : x(x_), y(y_) {} int x,y ; } inline point xform ( point const& p ) { return point(p.x*p.y,p*x.p.y); } int main() { point q(10,10); point& rq = q ; rq = xform(q); } AFAICT, 12.2 allows an implementation to construct the result value of xform right in the caller's LHS (rp in this case). Now, being 'rq' an alias for 'q'; and given that the 'p' (the function argument) is itself another alias for 'p', I think that it is possible for the call to give the "wrong" result (because p.x or p.y might changed in the middle) Is it true that p.x/p.y might be changed in the middle of the result construction because of the aliasing? TIA Fernando Cacciola SciSoft --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ben Hutchings Guest Posted: Mon Feb 23, 2004 5:26 pm    Post subject: Re: return value optimization and aliasing Fernando Cacciola wrote: Quote: Hi, Consider: struct point { point( int x_, int y_ ) : x(x_), y(y_) {} int x,y ; } inline point xform ( point const& p ) { return point(p.x*p.y,p*x.p.y); } int main() { point q(10,10); point& rq = q ; rq = xform(q); } AFAICT, 12.2 allows an implementation to construct the result value of xform right in the caller's LHS (rp in this case). snip No, it doesn't. Logically what happens is that xform constructs a temporary point(), copies that to its return value (another temporary), then main() copies that to a third temporary and assigns that to rq (i.e. q). The implementation is allowed to avoid the two copies but it cannot convert an assignment into an initialisation. The assignment to rq (i.e. q) must be done separately from the construction of the new point. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top James Kuyper Guest Posted: Mon Feb 23, 2004 5:26 pm    Post subject: Re: return value optimization and aliasing "Fernando Cacciola" <fernando_cacciola (AT) hotmail (DOT) com> wrote Quote: Hi, Consider: struct point { point( int x_, int y_ ) : x(x_), y(y_) {} int x,y ; } inline point xform ( point const& p ) { return point(p.x*p.y,p*x.p.y); } int main() { point q(10,10); point& rq = q ; rq = xform(q); } AFAICT, 12.2 allows an implementation to construct the result value of xform right in the caller's LHS (rp in this case). Now, being 'rq' an alias for 'q'; and given that the 'p' (the function argument) is itself another alias for 'p', I think that it is possible for the call to give the "wrong" result (because p.x or p.y might changed in the middle) Is it true that p.x/p.y might be changed in the middle of the result construction because of the aliasing? No - RVO is subject to the restriction: "Even when the creation of the temporary object is avoided (12., all the semantic restrictions must be respected as if the temporary object was created." If the temporary object had been created, the problem that you describe couldn't occur. Therefore, the implmentation will have to generate code that will avoid that problem; most likely by creating at least one temporary that would otherwise have been removeable. --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Fernando Cacciola Guest Posted: Tue Feb 24, 2004 4:48 am    Post subject: Re: return value optimization and aliasing "James Kuyper" <kuyper (AT) wizard (DOT) net> escribió en el mensaje news:8b42afac.0402230903.2d790dc6 (AT) posting (DOT) google.com... Quote: "Fernando Cacciola" <fernando_cacciola (AT) hotmail (DOT) com> wrote Hi, Consider: struct point { point( int x_, int y_ ) : x(x_), y(y_) {} int x,y ; } inline point xform ( point const& p ) { return point(p.x*p.y,p*x.p.y); } int main() { point q(10,10); point& rq = q ; rq = xform(q); } AFAICT, 12.2 allows an implementation to construct the result value of xform right in the caller's LHS (rp in this case). Now, being 'rq' an alias for 'q'; and given that the 'p' (the function argument) is itself another alias for 'p', I think that it is possible for the call to give the "wrong" result (because p.x or p.y might changed in the middle) Is it true that p.x/p.y might be changed in the middle of the result construction because of the aliasing? No - RVO is subject to the restriction: "Even when the creation of the temporary object is avoided (12., all the semantic restrictions must be respected as if the temporary object was created." If the temporary object had been created, the problem that you describe couldn't occur. Therefore, the implmentation will have to generate code that will avoid that problem; most likely by creating at least one temporary that would otherwise have been removeable. OK, I follow your analysis based on the code as I wrote it. However, 12.2/2 explicitely says than in the case of expressions of the form: a=f(a) a temporary is required in order to avoid alisaing problems. My example simply intended to figure out when such aliasing could cause problems (that's why I used a reference a the caller's LHS), so, what would be a good example for the problems 12.2/2 is explicitely trying to avoid. I figure that depending on the concrete code the compiler might loose track of aliasing to correctly follow the as if rule (which is what prevents the problem in this particular example I wrote) TIA Fernando Cacciola SciSoft --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Alberto Barbati Guest Posted: Wed Feb 25, 2004 4:33 am    Post subject: Re: return value optimization and aliasing Fernando Cacciola wrote: Quote: I figure that depending on the concrete code the compiler might loose track of aliasing to correctly follow the as if rule (which is what prevents the problem in this particular example I wrote) Wait a moment. According to my interpretation, all optimization freedom granted by 12.2 and 12.8 is about avoiding "unnecessary" copy constructions. However the incriminated line rq = xform(q); is an assignment and not a copy construction. Under which circumstances an assignment can be replaced with a copy construction? Only in that case the compiler could possibly *construct* the result value of xform(q) directly into rq, therefore incurring in the aliasing problem. If type point were not a POD, the assignment could not be replaced by copy construction. However I could not find a statement in the standard stating that assignment can be replaced by copy construction for PODs. If all that I've said is correct, yours is a non-problem: the compiler can't choose to optimize and so aliasing can't occur. Maybe example 12.2/2 could be improved, as the line a = f(a) is a bit misleading (the problem is not having "a" twice but the presence of the assignment). Is there something I am missing? Alberto Barbati --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Ben Hutchings Guest Posted: Wed Feb 25, 2004 5:46 pm    Post subject: Re: return value optimization and aliasing Fernando Cacciola wrote: <snip> Quote: OK, I follow your analysis based on the code as I wrote it. However, 12.2/2 explicitely says than in the case of expressions of the form: a=f(a) a temporary is required in order to avoid alisaing problems. My example simply intended to figure out when such aliasing could cause problems (that's why I used a reference a the caller's LHS), so, what would be a good example for the problems 12.2/2 is explicitely trying to avoid. snip I think the example is in error - the temporary is required even if the actual argument to f() is some other variable. I don't see how the return value of f() can be constructed on top of a, since a has already been constructed and is now being assigned. Perhaps a defect report is in order? --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Fernando Cacciola Guest Posted: Thu Feb 26, 2004 3:50 am    Post subject: Re: return value optimization and aliasing "Ben Hutchings" <do-not-spam-benh (AT) bwsint (DOT) com> escribió en el mensaje news:slrnc3msb0.p3b.do-not-spam-benh (AT) shadbolt (DOT) i.decadentplace.org.uk... Quote: Fernando Cacciola wrote: snip OK, I follow your analysis based on the code as I wrote it. However, 12.2/2 explicitely says than in the case of expressions of the form: a=f(a) a temporary is required in order to avoid alisaing problems. My example simply intended to figure out when such aliasing could cause problems (that's why I used a reference a the caller's LHS), so, what would be a good example for the problems 12.2/2 is explicitely trying to avoid. snip I think the example is in error - the temporary is required even if the actual argument to f() is some other variable. I don't see how the return value of f() can be constructed on top of a, since a has already been constructed and is now being assigned. Perhaps a defect report is in order? I agree with you (and Alberto) that RVO can produce in-place "construction" (via intialization) but not assignment, so I think the example is misleading and a DR is in order. I'll post one later today. Thanks, Fenando Cacciola SciSoft --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ language, library and standards All times are GMT Page 1 of 1   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.