It will be interesting to see how the adoption of the syntax for blocks plays out. According to the wikipedia entry for GCD, the proposed C++0x standard has a similar concept, but uses square braces [] instead of the caret ^. The former could be brought down to C, but Objective-C, which is defined as a superset of C, already uses the square braces for object messaging.
Are there any C++ experts who could speak to whether there is any reason that the caret would not work in that language?
The C++0x feature you're referring to is for lamdas (anonymous functions). It might be possible to use another syntax, but it would make parsing (even more of) a nightmare because one can use "&" or "value" inside the square brackets to indicate if values should be pass by-value or by-reference.
In practical terms, I doubt the C++ committee would change the already delayed C++0x standard to accommodate a feature which may (but probably won't) make it into C.
FWIW, it looks like the concept of a block is also an anonymous function, although it looks as if they only allow passing into them by value, not by reference. The developer documentation at Apple indicates that they also support these within C++, and has a small section on how they behave within it. So, at least, they went the extra mile and worked out the C++ parsing issues.
I just encountered an interesting and relevant quotation from Chis Lattner:
"To head off the obvious question: this syntax and implementation has nothing to do with C++ lambdas. Blocks are designed to work well with C and Objective-C, and unfortunately C++ lambdas really require a language with templates to be very useful. The syntax of blocks and C++ lambdas are completely different, so we expect to eventually support both in the same compiler."
Microsoft would never support GCD. They will invent something similar completely incompatible that makes it difficult to port programs to any other platform.
I wish the headline would have been more specific and mention that this relates to Macs. I saw this headline on my phone while waiting for my table at a restaurant. I hurried my way back to work to sign up for it only to realize that it was not Google Voice / Grand Central. I guess I'll have to keep waiting for that.
Oh dear...I'm sorry about that. I copied the original headline verbatim, because I once saw someone get flamed for not doing so. This was my first HN submission.
It would be nice if this was back-ported to Leopard (so you could use GCD without the application being Snow Leopard only), I wonder how difficult this would be..
System-wide integration and being able to assume it's always present.
You're right in that, as far as I can tell, there are no new ideas in GCD. But it's integrated into the language, compiler, runtime system, kernel, and developers can assume that it is present on any Mac OS 10.6 and greater. That makes a big difference.
I've found very little documentation on this, but apparently the kernel optimizes multiple thread pools to prevent excessive context switches. (Consider an N-core system where multiple processes each create N worker threads of their own.)
Do you mean process migration (rescheduling a process/thread on a different core, which does bad things to caches) instead of context switching (switching between different processes/threads on the same core, which requires saving registers to memory and does bad things to caches)? If so, any decent modern scheduler tries to avoid migrating threads.
When I said context switching I meant context switching. Now that you mention it, GCD may also reduce thread migrations. I'm just speculating since we don't know how GCD works.
http://www.macresearch.org/cocoa-scientists-xxxi-all-aboard-...