On Wed, November 2, 2011 16:02, Sebastian Redl wrote: > On 02.11.2011 16:55, jahanian wrote: >> On Nov 2, 2011, at 7:59 AM, Douglas Gregor wrote: >>> On Nov 2, 2011, at 1:33 AM, John McCall wrote: >>>> On Oct 31, 2011, at 4:44 PM, Fariborz Jahanian wrote: >>>>> Author: fjahanian >>>>> Date: Mon Oct 31 18:44:33 2011 >>>>> New Revision: 143399 >>>>> >>>>> >>>>> URL: http://llvm.org/viewvc/llvm-project?rev=143399&view=rev >>>>> Log: >>>>> Adds IRGen support for captured rvalue references in blocks. >>>>> In this case, temporary value is copied into block descriptor >>>>> as their own copy to work on. // rdar://9971124 >>>> Sorry for missing this earlier, but I really don't think is the right >>>> thing to do. Block captures of l-value references capture a reference; >>>> making block captures of r-value references capture a copy is bizarrely >>>> inconsistent. >>> >>> What do you propose? Capture the reference, even though it's almost >>> surely going to refer to a temporary? >> In the absence of any precedence of how to treat rvalue reference in code >> gen. A compromise may be to make the copy as is currently done, but >> establish a reference to it on entry to the block. In essence, temporary is >> moved to the block descriptor. But I am not sure if this will make any >> difference in terms of semantics of such references. >> > What are the semantics of rvalue references captured by C++11 lambdas? > Even if there is no intuitive handling of the situation, following C++11 > lambdas would at least have the advantage of not having two *different* > surprising behaviors. (Or do C++'s explicit captures make the question moot?)
Inside lambdas, for a capture-by-copy of a reference to non-function type, a temporary is created for both kinds of reference (and the value is copied, not moved, into it in both cases). For a capture-by-reference, the name within the closure simply refers to the variable in the outer scope (there is no mandated implicit reference member, but that's a valid implementation strategy). The C++11 semantics generally are that *named* entities of rvalue reference types behave like lvalue references almost everywhere; it would seem strange to me if this behavior varied inside an ObjC block. But a huge pile of salt: I've never written a single line of ObjC, let alone ObjC++11 :) Richard _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
