Apple Blocks added to C++?

Jeremie Pelletier jeremiep at gmail.com
Wed Sep 2 09:10:54 PDT 2009


Michel Fortin Wrote:

> On 2009-09-02 00:27:46 -0400, S. <S at S.com> said:
> 
> > Been awhile since I posted.
> > 
> > I was wondering what other people thought about this addition to C++ by 
> > Apple.   Heh.
> > 
> > http://arstechnica.com/apple/reviews/2009/08/mac-os-x-10-6.ars/10
> 
> I don't find the syntax that ugly. And I'd say the feature is at its 
> best when used with Grand Central Dispatch. As page 13 of this same 
> review says, it enables developer to transform synchronous operations 
> such as this:
> 
>   NSDictionary *stats = [myDoc analyze];
>   [myModel setDict:stats];
>   [myStatsView setNeedsDisplay:YES];
>   [stats release];
> 
> into asynchrnous with minimal effort:
> 
>   dispatch_async(dispatch_get_global_queue(0, 0), ^{
>     NSDictionary *stats = [myDoc analyze];
>     dispatch_async(dispatch_get_main_queue(), ^{
>       [myModel setDict:stats];
>       [myStatsView setNeedsDisplay:YES];
>       [stats release];
>     });
>   });
> 
> Without it, you'd have to create a bunch of different functions, 
> probably accompanied by a context struct, to make this work, 
> complexifying the conde and making it harder to follow. It's just 
> syntaxic sugar when you think about it, but it's that syntaxic sugar 
> that makes it practical to express operations in a way they can run 
> asynchrnously.
> 
> -- 
> Michel Fortin
> michel.fortin at michelf.com
> http://michelf.com/
> 

How hard is it to implement asynchronous work queues anyways? Not hard at all.

Apple's blocks and global queue are not portable anyways. I would *much* rather use D delegates (which can be static functions, methods, closures or nested functions) and a process-local work queue.

There's a huge difference between complex code and long code, especially in compiled languages. Those 8 lines in your code are not convenient in that you don't get what they do on first sight. Declaring your things separately and then registering the closures to the queues would result in the exact same machine code being generated, but also be much easier to read.

The only place where I expect to see code unreadable like this is in scripting where the parser has an impact on the performance.

I also don't get why you need two closures on two different queues. My take at this in D would look like:

DispatchAsync({
   writefln("Look, async!");
});

No global queue to dispatch on the main queue, that's just redundant and slow, custom dispatcher that is portable, and D closures, simple and elegant :)



More information about the Digitalmars-d mailing list