[cfe-dev] blocks and lambdas

John McCall rjmccall at apple.com
Tue Feb 8 11:03:39 PST 2011


On Feb 8, 2011, at 10:44 AM, James Gregurich wrote:
> On Feb 7, 2011, at 8:00 PM, John McCall wrote:
>> On Feb 7, 2011, at 6:33 PM, James Gregurich wrote:
>>> What if you build your lambda structure around the existing block structure such that the lambda type would have a copy constructor that calls Block_copy? If the lambda has a type, it stands to reason that it could have a copy constructor.
>> 
>> You seem to be describing a transformation which would occur when a block pointer is treated like a lambda.
> 
> no. not really a "transformation"...more of a syntactic wrapper.  you control your compiler and runtime. When clang hits a lambda in C++ code, I assume the backend could generate a block structure to implement the lambda. Also, if the lambda has a c++ type, then it could also have a copy constructor to invoke Block_copy so that the mechanism works normally with stl. Is such an assumption off-base?

Okay, this is the opposite direction of interoperability from what I thought you were talking about;  this is using a lambda expression as if it were a block.  I certainly would like this to work;  this is what I was getting at by saying "an implicit conversion to the appropriate block pointer type".  We probably won't use the standard block layout, though, because it's a pretty substantial size overhead (4-5 pointers) that most C++ clients won't want.  Obviously, when a lambda expression is immediately converted to a block pointer, we'll want to just build it as a block in the first place.

>> That's not actually a knowable point in a program.
> 
> I don't understand what you mean by this statement.

I was talking about the opposite direction of interoperability, i.e. using a block expression or block pointer as if it were a lambda.  This is what's unsafe because of the dangling-pointer issue and that we can't really make safe because of how lambdas work.

John.



More information about the cfe-dev mailing list