[cfe-dev] blocks and lambdas

[James Gregurich]

given the lambda is the cross-platform standard, I think being able to pass the lambda to the Cocoa callback-using APIs and to libdispatch is the useful situation....ie...lambda being able to masquerade as a block and interoperate cleanly with Apple's home-grown infrastructure.  If I can write my code entirely in terms of lambda's and that code works with Apple's native stuff, I can't image why I would want to use a block with standard code. If did want to put a block into a STL container or some such thing, I could certainly create a wrapper template that performed the Block_copy.

If you can make that functionality happen, then I suppose that it will meet my needs and I'll be happy.

-James

On Feb 8, 2011, at 11:03 AM, John McCall wrote:

> 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.