On 04/11/13 06:18, pins...@gmail.com wrote: > > >> On Nov 3, 2013, at 9:10 PM, Ian Lance Taylor <i...@google.com> >> wrote: >> >>> On Sun, Nov 3, 2013 at 8:49 PM, <pins...@gmail.com> wrote: >>> >>> >>>> On Nov 3, 2013, at 8:28 PM, Maxim Kuvyrkov >>>> <ma...@kugelworks.com> wrote: >>>> >>>> Hi, >>>> >>>> I am considering a project to add Apple's blocks [*] extension >>>> to GCC. I am looking at adding blocks support to C, C++ and >>>> Obj-C/C++ front-ends. >>> >>> What benefits does blocks have over nested functions in C and >>> over lambas in C++? I think it is wrong to add another extension >>> if only to be compatible with clang. I also think the blocks >>> extension are less useful than nested functions and lambas. The >>> question really should be why support something which has no >>> advantage to them to what is already existing. I think it was >>> wrong for apple to add them in the first place. >> >> Clang's blocks are more powerful than GCC's nested functions, >> because blocks may be placed on the heap, and therefore returned >> from a function. > > Actually I think it is less powerful since it is a copy rather than a > reference. Then again lambas can be do both. >
The point is that a function can create a block that refers to the function's local variables, pass a pointer to that block somewhere (such as by returning it), and everything will still work - the data required for the block will be put on the heap. You can't do that with a gcc nested function. As far as I can see (from the Wikipedia article and a brief google), "blocks" are a mixture of C++ lambdas and functors. Like functors, you can use the heap to preserve the data and let the block exist beyond the defining scope. Like lambdas, you can capture local data without having to define the details and manually copy the data. Whether or not this is useful enough to implement, I don't know. But the Wikipedia article refers to an Apple fork of gcc with block support - forks like that are generally not an ideal situation for gcc. > >> >> Ian >
