Re:Uses for Blocks in C/Objective-C
by gprisament on Thursday November 19, 2009 @07:06PM
(#951513)
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.
Re:Uses for Blocks in C/Objective-C
by rbritton on Thursday November 19, 2009 @07:11PM
(#951521)
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.
Re:Uses for Blocks in C/Objective-C
by wtallis on Thursday November 19, 2009 @08:56PM
(#951669)
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".
Re:Uses for Blocks in C/Objective-C
by antonovka on Thursday November 19, 2009 @08:34PM
(#951639)
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.
Re:Uses for Blocks in C/Objective-C
by msie on Thursday November 19, 2009 @08:35PM
(#951643)
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
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".
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.
Speaking of which, are blocks supported by the iPhone's objC runtime?
UPDATE:
Unofficial support exists right now:
http://code.google.com/p/plblocks/