Comments on: Blocks/Closures For C! http://jens.mooseyard.com/2008/08/blocksclosures-for-c/ Little boxes made of words, by Jens Alfke Sun, 14 Mar 2010 11:32:26 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Johannes Fortmann http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2756 Johannes Fortmann Fri, 05 Sep 2008 16:22:55 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2756 Actually, Chris' post is about how Apple has already added Blocks to gcc, and now is adding them to clang. They prototyped them in clang, then implemented them in gcc, and now are adding the final implementation back to clang. If you check out the llvm-gcc svn trunk, you'll find all the code there (you can even build your own llvm-gcc with working blocks). Of course, as with all Apple features in gcc, it will take ages till the features get merged into the FSF branch. Mainline gcc still doesn't have a single objc-2.0 feature merged (and since nobody seems to care enough, I doubt that'll ever happen). Pity; they'd be just as useful on the other platforms gcc supports. Actually, Chris’ post is about how Apple has already added Blocks to gcc, and now is adding them to clang. They prototyped them in clang, then implemented them in gcc, and now are adding the final implementation back to clang. If you check out the llvm-gcc svn trunk, you’ll find all the code there (you can even build your own llvm-gcc with working blocks).

Of course, as with all Apple features in gcc, it will take ages till the features get merged into the FSF branch. Mainline gcc still doesn’t have a single objc-2.0 feature merged (and since nobody seems to care enough, I doubt that’ll ever happen). Pity; they’d be just as useful on the other platforms gcc supports.

]]> By: Jens Alfke http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2755 Jens Alfke Thu, 04 Sep 2008 16:21:47 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2755 Timothy — I would guess that Apple won't be putting blocks into gcc, since they're switching over to Clang. (The complexity of gcc, and the GPL license, make it hard to integrate its parser into Xcode in the ways Apple wants to do in the future to support better syntax-driven editing and code refactoring.) But of course gcc is open source, so someone else could add blocks to it if they wanted. As I understand it, a block pointer is a first-class data type, so you can store them in variables, pass them as arguments, et cetera; whatever you could do with a regular C function pointer. Timothy — I would guess that Apple won’t be putting blocks into gcc, since they’re switching over to Clang. (The complexity of gcc, and the GPL license, make it hard to integrate its parser into Xcode in the ways Apple wants to do in the future to support better syntax-driven editing and code refactoring.) But of course gcc is open source, so someone else could add blocks to it if they wanted.

As I understand it, a block pointer is a first-class data type, so you can store them in variables, pass them as arguments, et cetera; whatever you could do with a regular C function pointer.

]]> By: Timothy Mowlem http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2754 Timothy Mowlem Thu, 04 Sep 2008 11:44:16 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2754 Will this feature be added to gcc as well or just to Clang. Also will it be possible to store a block definition into a variable to store and pass as an argument, or will only anonynous blocks be supported? Will this feature be added to gcc as well or just to Clang. Also will it be possible to store a block definition into a variable to store and pass as an argument, or will only anonynous blocks be supported?

]]> By: Jens Alfke http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2753 Jens Alfke Tue, 02 Sep 2008 15:24:26 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2753 Andy — A block is <i>not</i> just a function pointer. It's a "closure" that carries along a reference to the variables in scope at the time the block was created. At runtime that involves an invisible extra parameter, plus some fairly complex bookkeeping to handle the case where the block's scope exits from the stack while the block is still alive. Also, I'm pretty certain that the compiler wouldn't be able to parse an expression like "call_a_block((int y){ print(X+y); })" — it needs some indicator, like "^", to tell it where the block subexpression begins. Andy — A block is not just a function pointer. It’s a “closure” that carries along a reference to the variables in scope at the time the block was created. At runtime that involves an invisible extra parameter, plus some fairly complex bookkeeping to handle the case where the block’s scope exits from the stack while the block is still alive.

Also, I’m pretty certain that the compiler wouldn’t be able to parse an expression like “call_a_block((int y){ print(X+y); })” — it needs some indicator, like “^”, to tell it where the block subexpression begins.

]]> By: Andy Somogyi http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2752 Andy Somogyi Tue, 02 Sep 2008 14:52:54 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2752 Why do they have to add the '^' operator?, would it not be possible to just create a 'block' or anonymous function inline, and pass it to any old C function that takes a function pointer? Why do they have to add the ‘^’ operator?, would it not be possible to just create a ‘block’ or anonymous function inline, and pass it to any old C function that takes a function pointer?

]]> By: Jens Alfke http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2751 Jens Alfke Mon, 01 Sep 2008 18:51:29 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2751 Carlos — Blocks are being added to the C compiler; there's nothing specific to Objective-C about them, so they could be used in arbitrary C code, as long as you're compiling it with Clang. Carlos — Blocks are being added to the C compiler; there’s nothing specific to Objective-C about them, so they could be used in arbitrary C code, as long as you’re compiling it with Clang.

]]> By: charles http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2750 charles Mon, 01 Sep 2008 13:48:47 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2750 Thanks, it will be very interesting to follow this 'thread'. There is apparently not much out there about Blocks, so maybe the readers of this post will be interested in <a href="http://www.macresearch.org/cocoa-scientists-part-xxvii-getting-closure-objective-c" rel="nofollow">a post on macresearch.org</a>. Thanks, it will be very interesting to follow this ‘thread’. There is apparently not much out there about Blocks, so maybe the readers of this post will be interested in a post on macresearch.org.

]]> By: Carlos http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2749 Carlos Mon, 01 Sep 2008 07:51:58 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2749 It seems very interesting. Are Blocks being designed only for Objetive-C, or there will be an ANSI-C version too? It seems very interesting. Are Blocks being designed only for Objetive-C, or there will be an ANSI-C version too?

]]> By: Mark Onyschuk http://jens.mooseyard.com/2008/08/blocksclosures-for-c/comment-page-1/#comment-2748 Mark Onyschuk Sun, 31 Aug 2008 13:10:56 +0000 http://mooseyard.com/Jens/2008/08/blocksclosures-for-c/#comment-2748 Spectacular news! I'd long ago given up hope that we'd see this kind of fundamental change in Objective C. The relatively modest changes to the language introduced in Objective C 2.0 seemed to cement that for me. Mark Spectacular news! I’d long ago given up hope that we’d see this kind of fundamental change in Objective C. The relatively modest changes to the language introduced in Objective C 2.0 seemed to cement that for me.

Mark

]]>