Uses for Blocks in C/Objective-C | Hacker News Reader

Uses for Blocks in C/Objective-C

macresearch.org

19 pointsrtrunck8 comments

The big appeal of C for me is that it's portable (as long as you know to avoid the non-portable parts, anyway). Sorry, but I won't be using any language extension that will only compile on mac. And anyway, function pointers aren't that hard to groc.

The biggest benefit of blocks over function pointers to me, though, is that the code resides exactly where it's being called. Function pointers have a nasty habit of not necessarily doing the same. While the syntax is a bit wonky at first, I think it results in cleaner code overall.

To my knowledge, Apple hasn't submitted Blocks to any standards body, but that doesn't mean that they don't want it adopted by other systems. They've open-sourced libdispatch, which is most useful with Blocks, and it's been picked up for FreeBSD. Unfortunately, Blocks conflicts with the C++0x proposal for lambdas, which itself conflicts with the Objective-C message notation. However, it seems likely that there will soon (on the timescale of language standardization) be reconciliation and a standard notation for lambdas and closures for C and friends. Libdispatch will almost certainly be compatible with that notation, and be available on most *nix systems that are likely to adopt things like C++0x relatively quickly.

In light of that, one could see Blocks as Apple wanting to ensure that at least one closures-for-C implementation starts getting real-world exposure, much as OpenCL was their way of ensuring that there is at least one vendor-neutral GPGPU API, even if it isn't the best possible. If their methods do end up becoming de facto standards , Apple could gain a lot by being the preferred and most mature implementation. If not, there's no real harm to Apple, because their platform is already "different".

The big appeal of C for me is that it's portable (as long as you know to avoid the non-portable parts, anyway). Sorry, but I won't be using any language extension that will only compile on mac.

I agree, but the compiler changes are open source, and I'm happy to use them on a Mac (where I'm already using ObjC anyway).

And anyway, function pointers aren't that hard to groc.

Function pointers aren't closures. "Groking" isn't the issue -- accomplishing more with less code and fewer bugs is.

If you are programming in Objective-C and for the Mac you might as well forget about portability. I hope they add more language extensions to Objective-C to make it more pleasant to program in than it is now. I'd like a better way to express lists and hashes please. And garbage collection too. :D

Garbage collection is already there in ObjC 2.0.

...but not on the iPhone.

Speaking of which, are blocks supported by the iPhone's objC runtime?

UPDATE:

Unofficial support exists right now:

http://code.google.com/p/plblocks/

The code is free and open. Download it and port it to your platform of choice. You can't expect Apple to port their code to Linux for you.

Reply on news.ycombinator.com