[cfe-dev] blocks and lambdas

James Gregurich bayoubengal at mac.com
Wed Feb 9 15:48:53 PST 2011

On Feb 9, 2011, at 2:00 AM, David Chisnall wrote:

> Lambdas and blocks are orthogonal technologies.

How are they orthogonal? I see a ton of overlap between the two....at least conceptually.

>  Blocks are a C extension designed to interoperate nicely with Objective-C and to work with C++.  Lambdas are a (very different) C++ technology.  Saying that you want a C library (libdispatch) to support a C++ technology (lambdas) doesn't make much sense.  

Why is the following structure incapable of describing a C++ lambda function? 

struct Block_basic {
    void *isa;
    int Block_flags;  /* int32_t */
    int Block_size; /* XXX should be packed into Block_flags */
    void (*Block_invoke)(void *);
    void (*Block_copy)(void *dst, void *src);  /* iff BLOCK_HAS_COPY_DISPOSE */
    void (*Block_dispose)(void *);             /* iff BLOCK_HAS_COPY_DISPOSE */
    /* long params[0];  // where const imports, __block storage references, etc. get laid down */

If the clang C compiler can set up this structure for a Blocks block, I don't see why the clang C++ compiler cannot do the analogous operation with a C++ lambda.

whether it is C or C++, it's all just symbols and structures. 

> Given the different semantics between blocks and lambdas, implementing one in terms of the other does not really make sense.  However, it would be fairly simple at the library level to implement a wrapper for one in terms of the other, so this isn't a compiler issue, it's an issue for your code.  

Why do the semantics of the languages matter? They are conceptually the same thing. The only difference I see is the __blocks keyword/ block storage. My point earlier is don't worry about block storage for lambdas. C++ programmers are expected to understand the lifetimes of their variables and not use them in ways inconsistent with their scope....also, if one wants to share variables with the stack and multiple blocks, he'll declare the variable as a shared_ptr anyway. The block/lambda just needs to copy the shared_ptr by value.

> Having blocks and labmdas share an implementation in clang would be problematic for a variety of reasons.  For one thing, blocks already have a well-defined ABI, and lambdas will have a per-platform ABI.  Unless you could persuade the C++ committee to break with tradition and specify an ABI, and specify that ABI to be compatible with the existing, deployed, blocks ABI, then this is not feasible.  

The behavior can be specific to MacOSX where Apple controls the platform and ABI. I doubt there is extensive blocks use outside of the Apple universe. So, interoperability doesn't matter outside the Apple universe. Apple doesn't support newer versions of gcc that support lambdas and clang doesn't do lambdas yet, so there should still be the freedom to pick a meaningful ABI for Apple platforms that makes the two technologies compatible. If Apple can change its ABIs to unify C++ and ObjC exceptions, then surely it can set up its ABI to make blocks and lambdas interoperable.

Bottom line....

I'm a 3rd party developer that has to share code between OSX and Windows....a description I'd say likely applies to the majority of mac developers. The clang team is building this compiler for people like me to use. My statement is....don't make me, the customer, have to go through coding gymnastics to make my standard code work with Apple's platforms. Don't force me to use non-standard code structures for force me to have to write compatibility wrappers unless it is necessary. This stuff is extra work that makes my code more complex and less maintainable.

I'm not going to put on any pretense that I understand the technology necessary to make blocks and lambdas interoperable. I have a fair amount of knowledge, but this is not my area of expertise. I don't daily work on compilers and libraries. I'm doing my best to communicate (as a general statement) to you guys who are compiler and library guys that we need to maximize interoperability with C++ standards and Apple-specific APIs so that people like me can deliver higher quality apps to market more quickly. I don't think that is an unreasonable statement.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110209/81d509a2/attachment.html>

More information about the cfe-dev mailing list