[cfe-commits] r143399 - in /cfe/trunk: lib/CodeGen/CGBlocks.cpp lib/CodeGen/CGExpr.cpp test/CodeGenCXX/block-rvalue-reference-capture.cpp

Sebastian Redl sebastian.redl at getdesigned.at
Wed Nov 2 09:02:14 PDT 2011


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?)

Alternatively, we could just forbid the capturing of rvalue references. 
Let the user make an explicit choice by either creating a local copy or 
a local lvalue reference.

Sebastian



More information about the cfe-commits mailing list