views:

469

answers:

5

http://clang.llvm.org/docs/BlockLanguageSpec.txt

Looks really cool.

However,

  1. I don't understand it.
  2. I don't see examples it.
  3. I don't see examples of ideas hard to express in C++ as is, but trivial to express in blocks.

Can anyone enlighten me on this?

Thanks!

+1  A: 

As far as I understand this extension is for Apple's Grand Central Dispatch framework. Blocks are tiny schedulable/queue-able entities to be potentially run in parallel.

Nikolai N Fetissov
+1  A: 

They're basically just Apple's term for closures/anonymous functions. As Nikolai notes, they're how you use Grand Central Dispatch to run multiple functions in parallel (thus using more than 1 core) without having to worry about threading and locking.

Brock Batsell
Not Apple's terminology. The terminology comes from Smalltalk. Objective-C can be seen as a hybrid of C and Smalltalk. An earlier non-Apple/non-Next Objective-C compiler (called PoC) had added blocks many years ago and used the Smalltalk terminology. So it's only natural that Smalltalk terminology was used for Apple's implementation, too.
trijezdci
I didn't intend to imply that Apple had invented it, just that that's the term they chose to use for Objective-C 2.0 (and, by extension, that of the clang project funded by Apple).
Brock Batsell
I think Objective-C was quite heavily influenced by Smalltalk and took on quite a bit of the terminology. Objective-C has been around for quite a while (IIRC it's actually older than C++) and at the time Smalltalk was the gold standard for this sort of thing.
ConcernedOfTunbridgeWells
+4  A: 

Blocks are, essentially, a way to pass code and scope around as data. They're known in some other languages as closures and anonymous functions.

Here's an article with more details and code examples.

NanoTech
BTW the next version of C++ has closures as well, via lambda syntax.
Ben Voigt
A: 

NanoTech already linked to an explanation of blocks. As for how this relates to C++ let me state my personal opinion: This extension is not useful in C++. Here's why:

Regarding the block reference type: We already have "polymorphic functions" which can carry some state around, see boost::function, tr1::function. C++ will include a polished version of this in its next standard library. The advantage over "C Blocks" is that you don't need to mess with things like Block_copy and Block_release. These polymorphic functions objects are smart enough to do their own memory managing.

Regarding the block literal syntax: It's a nice syntax that allows you to put the code where it "belongs" without the need for much boilerplate code. But the same applies to its C++ counter part: C++0x lambdas. But C++0x lambda feature also allows you to use lambda objects in tight inner loops without high performance costs of function calls due to possible inlining.

Since C++0x lambdas can be also used in situations where performance is an issue and std::function is easier to handle w.r.t. memory management the addition of "C Blocks" to C++ seems redundant. "C blocks" seem to be more tailored to languages that don't support templates or destructors.

sellibitze
I'm not sure you mean what you think you mean when you say “polymorphic”.
Jonathan Sterling
@Jonathan: I didn't invent the term. See the current C++ standard draft (N3092.pdf), section 20.8.15, "Polymorphic function wrappers". They are polymorphic in the sense that you can wrap any function object in there as long as the signatures are compatible. The exact type of the wrapped object is hidden ("erased"). This is achieved via "classic OOP polymorphism" (or something equivalent).
sellibitze