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

Douglas Gregor dgregor at apple.com
Wed Nov 2 14:40:35 PDT 2011

On Nov 2, 2011, at 2:40 PM, jahanian wrote:

> On Nov 2, 2011, at 2:31 PM, Douglas Gregor wrote:
>> On Nov 2, 2011, at 12:48 PM, John McCall wrote:
>>>> What do you propose? Capture the reference, even though it's almost surely going to refer to a temporary?
>>> Yes.  References are references.
>>> Among the things that are wrong with doing a copy:
>>> (1) It's inconsistent with the capture of l-value references.
>>> (2) In my experience, l-value references are about equally likely
>>> to point into something stored on or owned by the stack, so it's
>>> not like those are really any safer.
>>> (3) C++ programmers using blocks are certain to deal with both
>>> reference types and therefore to be surprised by the inconsistency.
>>> (4) It has to be a copy, not a move, even though it's an r-value
>>> reference and the programmer presumably actually cares.
>>> (5) Capturing a reference to a temporary or local is not actually
>>> dangerous except in situations where the block is copied to the
>>> heap, but there are plenty of APIs that don't need to do this.
>>> (6) Unlike lambdas, there's no way to override this behavior, so
>>> this is actually a pretty strong expressivity constraint, and the
>>> workarounds either involve extra moves or terrible things like
>>> capturing a pointer to the temporary.
>> Okay, I agree. Let's go with capturing these as references. Thanks, John.
> This was how it was treated before I made the change. We captured the reference, but could not write to 
> the referenced object in the block. Will back out the change.


	- Doug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111102/70c61f08/attachment.html>

More information about the cfe-commits mailing list