• Jeremie Pelletier <jeremiep gmail.com> Sep 02 2009
• asd <asd none.invalid> Sep 02 2009

Jeremie Pelletier <jeremiep gmail.com> writes:

Michel Fortin Wrote:

 On 2009-09-02 00:27:46 -0400, S. <S 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 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 :)

asd <asd none.invalid> writes:

Jeremie Pelletier Wrote:

 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.


I disagree. That depends on type of code and is also a matter of taste. 

For example in JavaScript, where there's no difference between functions and
lambdas, I prefer to use deeply nested anonymous functions rather than function
declarations beforehand. I often find that more readable and I prefer
definition and use of the function in one place.

 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 :)


In that example global serial queue is used as synchronisation mechanism. It is
needed to interact with Cocoa UI properly.

Of course D has nicer syntax than C blocks. But in context of C, given its
already-awkward syntax for function types, limitations and compatibility
needed, blocks are quite good.