[cfe-dev] blocks and lambdas

[Bruno Santos]

Qua, 2011-02-09 às 15:48 -0800, James Gregurich escreveu:
> 
> 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 */
> };
> 

It can't, a lambda can be used as a function pointer!

Lambdas are syntactic sugar for function objects, which is fundamentally
different from what blocks are. What you are asking is lot of baggage
for nothing, from a pure C++ perspective, just to be compatible with
blocks.

> 
> 
> 
> 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.
> 
> 
> 
> 
> -James
> 
> 
> 
> 
> 
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5428 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110210/17a78869/attachment.bin>