www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Apple Blocks added to C++?

reply S. <S S.com> writes:
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
Sep 01 2009
next sibling parent Rainer Deyke <rainerd eldwood.com> writes:
S. wrote:
 Been awhile since I posted.
 
 I was wondering what other people thought about this addition to C++ by
 Apple.   Heh.
It doesn't solve any major problem and the syntax is ugly. If it was standard C++, I'd use it anyway. Since it isn't, I'll stick with Boost.Lambda (which is more limited and much uglier, but portable). -- Rainer Deyke - rainerd eldwood.com
Sep 01 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
S. wrote:
 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 find it strange that people are continuing to reinvent nested functions in ugly ways.
Sep 01 2009
next sibling parent reply Tim M <tim.matthews7 gmail.com> writes:
Nick Sabalausky Wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h7l32i$ev$1 digitalmars.com...
 S. wrote:
 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 find it strange that people are continuing to reinvent nested functions in ugly ways.
No offense, but Ruby and Python users would probably get a good chuckle at hearing the D creator saying that ;) But in the case of C/C++, I consider it a minor miracle that they were able to pull it off without making it 10x uglier than what they actually ended up with.
Walter: may I ask with this, reddit posts and dobb's code post, why the interest in this particular topic right now? Didn't you implement this a long time ago?
Sep 01 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Tim M wrote:
 Walter: may I ask with this, reddit posts and dobb's code post, why
 the interest in this particular topic right now? Didn't you implement
 this a long time ago?
It was one of the first things implemented in D. But I was thinking about it lately as I prepare the materials for the Compiler Construction seminar in a few weeks. Everyone tells me they are simple and obvious, yet in language after language they get added in bizarre ways that suggest that *somebody*, me or them, is just not getting it. So I thought it was time for an article. I mean, how can one miss the most stunningly obvious syntax: int foo(int a) { int bar(int i) { return a + 3; } return bar(3); } and that nested functions are useful for many more things than passing around pointers to them. For example, as helper functions.
Sep 02 2009
parent reply grauzone <none example.net> writes:
Walter Bright wrote:
 Tim M wrote:
 Walter: may I ask with this, reddit posts and dobb's code post, why
 the interest in this particular topic right now? Didn't you implement
 this a long time ago?
It was one of the first things implemented in D. But I was thinking about it lately as I prepare the materials for the Compiler Construction seminar in a few weeks. Everyone tells me they are simple and obvious, yet in language after language they get added in bizarre ways that suggest that *somebody*, me or them, is just not getting it. So I thought it was time for an article. I mean, how can one miss the most stunningly obvious syntax: int foo(int a) { int bar(int i) { return a + 3; } return bar(3); } and that nested functions are useful for many more things than passing around pointers to them. For example, as helper functions.
It has been a GCC extension for a long time: http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65
Sep 02 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
grauzone wrote:
 It has been a GCC extension for a long time:
 
 http://gcc.gnu.org/onlinedocs/gcc-2.95.3/gcc_4.html#SEC65
Which further makes it a mystery why this has to be badly reinvented. (But note that the gcc extension has the same problem D1 has with them; the closures don't survive the end of the function. This was fixed with D2.)
Sep 02 2009
prev sibling next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h7l32i$ev$1 digitalmars.com...
 S. wrote:
 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 find it strange that people are continuing to reinvent nested functions in ugly ways.
No offense, but Ruby and Python users would probably get a good chuckle at hearing the D creator saying that ;)
Perhaps they would, but I think they would agree that a nested function should follow the same syntax as a regular function.
 But in the case of C/C++, I consider it a minor miracle that they were able 
 to pull it off without making it 10x uglier than what they actually ended up 
 with.
For C++0x it's unnecessarily complicated - and they still don't have just plain old nested functions. C has no nested functions.
Sep 02 2009
parent reply Martin Franhaufer <zoogang telefonica.es> writes:
Walter Bright Wrote:

 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h7l32i$ev$1 digitalmars.com...
 S. wrote:
 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 find it strange that people are continuing to reinvent nested functions in ugly ways.
No offense, but Ruby and Python users would probably get a good chuckle at hearing the D creator saying that ;)
Perhaps they would, but I think they would agree that a nested function should follow the same syntax as a regular function.
Yes - Pascal has been doing that for years :-)
 But in the case of C/C++, I consider it a minor miracle that they were able 
 to pull it off without making it 10x uglier than what they actually ended up 
 with.
For C++0x it's unnecessarily complicated - and they still don't have just plain old nested functions. C has no nested functions.
Sep 02 2009
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Martin Franhaufer wrote:
 Yes - Pascal has been doing that for years :-)
I know, I learned it from Pascal.
Sep 02 2009
prev sibling parent reply Leandro Lucarella <llucax gmail.com> writes:
Martin Franhaufer, el  2 de septiembre a las 03:49 me escribiste:
 Walter Bright Wrote:
 
 Nick Sabalausky wrote:
 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:h7l32i$ev$1 digitalmars.com...
 S. wrote:
 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 find it strange that people are continuing to reinvent nested functions in ugly ways.
No offense, but Ruby and Python users would probably get a good chuckle at hearing the D creator saying that ;)
Perhaps they would, but I think they would agree that a nested function should follow the same syntax as a regular function.
Yes - Pascal has been doing that for years :-)
GCC support them as an extension to C for ages too. -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- A veces quisiera ser un barco, para flotar como floto siendo humano, y no hundirme como me hundo
Sep 02 2009
parent reply Mattias Holm <mattias.holm openorbit.REMOVE.THIS.org> writes:
Leandro Lucarella wrote:

 GCC support them as an extension to C for ages too.
 
True for nested functions but nested functions are not blocks. typedef void (*foo_t)(void); foo_t getSomeFunc() { int x = 4; void bar(void) { printf("%d\n", x); } return bar; } foo_t func = getSomeFunc(); func(); // Undefined, nested functions cannot be returned and in any case, no variable capturing will happen, so the variable x is undefined when func is called above getSomeFunc. On the contrary, the following would work very well with blocks: typedef void (^foo_t)(void); foo_t getSomeBlock() { int x = 4; void ^bar(void) { printf("%d\n", x); } return Block_copy(bar); } foo_t blk = getSomeBlock(); blk(); // Will happily print 4 Block_release(blk); // free up memory of block Though, they could probably make some hacks to gcc to add the copying and variable capturing to nested functions. Such hacks would most likely break a lot of code as the ABIs would have to be changed. This means that blocks are very suitable for enqueuing in something using the thread pool pattern, this is what GCD does and in my humble opinion GCD is a very very nice concurrency model for C. The main issues now being that GCD is seriously in need of standardisation through POSIX, and the C language. I suppose that blocks will not be added to C officially for quite some time, and therefore neither in POSIX. I think they should work out a version of C that includes that in the standard, like they have done for embedded applications, i.e. a set of extensions to the core language. / Matt
Sep 02 2009
parent Leandro Lucarella <llucax gmail.com> writes:
Mattias Holm, el  2 de septiembre a las 18:08 me escribiste:
 Leandro Lucarella wrote:
 
GCC support them as an extension to C for ages too.
True for nested functions but nested functions are not blocks.
I know, you removed the context of my response, I was refering to nested functions... -- Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/ ---------------------------------------------------------------------------- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) ---------------------------------------------------------------------------- Hoy estuvimos en el museo de antropología, pero yo voy a volver para estar por lo menos un día ahí adentro... es una locura, como Disney pero de indigenas -- Carla Lucarella (10/2008 contando de su viaje a México)
Sep 02 2009
prev sibling parent reply Mattias Holm <mattias.holm openorbit.REMOVE.THIS.org> writes:
Walter Bright wrote:
 S. wrote:
 I find it strange that people are continuing to reinvent nested 
 functions in ugly ways.
The blocks are not nested functions, they are more like closures. There are some block copy functions that move a block to the heap (including the captured variables). Nested functions can usually not be called after the defining function have returned. You cannot return blocks directly (since they are located on the stack), but you can return a heap copy of the block.
Sep 02 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Mattias Holm wrote:
 Walter Bright wrote:
 S. wrote:
 I find it strange that people are continuing to reinvent nested 
 functions in ugly ways.
The blocks are not nested functions, they are more like closures.
Nested functions do closures in a straightforward way, so by leaving off nested functions they were forced to make an ugly syntax <g>. This is why I shake my head in just not understanding the process that led to their design.
 There 
 are some block copy functions that move a block to the heap (including 
 the captured variables).
 
 Nested functions can usually not be called after the defining function 
 have returned. You cannot return blocks directly (since they are located 
 on the stack), but you can return a heap copy of the block.
This is handled in D automatically.
Sep 02 2009
next sibling parent reply Reimer Behrends <behrends gmail.com> writes:
Walter Bright wrote:
 Nested functions do closures in a straightforward way, so by leaving off 
 nested functions they were forced to make an ugly syntax <g>. This is 
 why I shake my head in just not understanding the process that led to 
 their design.
That is because nested functions and block closures have different purposes. Block closures avoid delocalization of code. For example, in Smalltalk, you could write something like the following to calculate the sum of the first 100 integers: s := 0. 1 to: 100 do: [ :i | s := s + i ]. Packaging the 's := s + i' block inside a nested function instead would (aside from unnecessarily having to also pass 's' by reference or by value-result to the function) require you to move back and forth between the piece of code above and the nested function in order to comprehend it. More generally, it allows you to write custom control structures, such as map, fold, and filter to generate more compact an coherent code. This is especially prevalent in functional languages (Scheme, LISP, Haskell, the whole ML family) and Smalltalk or Ruby. Research seems to indicate [1] that there is indeed a measurable readability benefit to this style of programming. The benefit of nested functions is something different. In essence, a nested function allows you to share state with the parent function (absent shared state, there is little reason to not make the nested function a top-level function instead). However, nested functions are hidden inside their parent, which means that they are not reusable; on top of that, object-oriented languages already have means to share state between multiple methods (which is sometimes imperfect, but so are nested functions). So, there are perfectly good reasons to have block closures, but not nested functions. Obviously, there are trade-offs, which may not appeal to everybody, but the design is still a rational one. Reimer Behrends [1] http://infoscience.epfl.ch/record/138586
Sep 03 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Reimer Behrends wrote:
 The benefit of nested functions is something different. In essence, a 
 nested function allows you to share state with the parent function 
 (absent shared state, there is little reason to not make the nested 
 function a top-level function instead).
The reason for nested functions are: 1. factoring out repeated code within the function into a nested function 2. locality - a nested function is adjacent to where it is used, rather than somewhere else 3. isolation - by scope rules, it is easy to see the nested function and all calls to it These may be mundane, but they make for the code being more readable than the clumsy workarounds necessary without them. They can also often be inlined by the compiler, making them a no-cost abstraction.
 However, nested functions are 
 hidden inside their parent, which means that they are not reusable;
That's actually a feature, see (3).
 on 
 top of that, object-oriented languages already have means to share state 
 between multiple methods (which is sometimes imperfect, but so are 
 nested functions).
Nested classes (Java) and functors (C++) are pretty ugly next to nested functions. One could argue that gcc has them as an extension but nobody uses them. My experience with adding extensions to DM C++ is that nobody uses them because it is non-standard, not because they are a bad idea.
 So, there are perfectly good reasons to have block closures, but not 
 nested functions. Obviously, there are trade-offs, which may not appeal 
 to everybody, but the design is still a rational one.
 
 
             Reimer Behrends
 
 
 [1] http://infoscience.epfl.ch/record/138586
Sep 03 2009
next sibling parent reply Reimer Behrends <behrends gmail.com> writes:
Walter Bright wrote:
 The reason for nested functions are:
 
 1. factoring out repeated code within the function into a nested function
 
 2. locality - a nested function is adjacent to where it is used, rather 
 than somewhere else
 
 3. isolation - by scope rules, it is easy to see the nested function and 
 all calls to it
You don't actually need nested functions for that. Consider, for example, Tarjan's algorithm [1] to find strongly connected components in a directed graph. It's normally a prime example of where you would use nested functions: It's got some scaffolding to set up temporary state, then repeatedly calls a recursive helper algorithm that operates on the temporary state. Without going into the details of the algorithm, you can basically write it as follows (using Scala as an example, though of course it would also work in D, OCaml, etc.): class DirectedGraph[V] { ... def stronglyConnectedComponents: Set[Set[V]] = { def recursiveHelper(vertex: V) = { ... } ... } ... } However, you could also factor out the algorithm into a class of it's own: class StronglyConnectedComponents[V](val graph: DirectedGraph[V]) { def findAll: Set[Set[V]] = { ... } private def recursiveHelper(vertex: V) = { ... } } This satisfies all your three criteria above. The potentially repeated code is factored out into its own function, the helper function is next to where it is used, and you can see who call it since it is private. However, unlike a nested function, you have additional benefits: You can reuse the helper function, for starters. And since the algorithm isn't an integral part of the DirectedGraph class anymore, you can furthermore improve the refactoring, since the algorithm doesn't need the full graph, but only a set of vertices and a successor function: class StronglyConnectedComponents[V](val vertices: Set[V], val successors: V => Set[V]) { def findAll: Set[Set[V]] = { ... } private def recursiveHelper(vertex: V) = { ... } } Now we can use the algorithm not only for directed graphs, but also for other, similar data structures that do not need to be a subtype of DirectedGraph.
 However, nested functions are hidden inside their parent, which means 
 that they are not reusable;
That's actually a feature, see (3).
As I showed above, you can have both locality and reusability. These are not mutually exclusive properties.
 on top of that, object-oriented languages already have means to share 
 state between multiple methods (which is sometimes imperfect, but so 
 are nested functions).
Nested classes (Java) and functors (C++) are pretty ugly next to nested functions.
I am not even talking about nested classes, just classes (see above). Classes are the standard vehicle in most object-oriented languages for having multiple functions operating on shared state. Mind you, I'm not saying that this is the only approach to deal with such issues (and it has imperfections of its own). Just that it is an alternative, equally valid way of doing things. Reimer Behrends [1] http://en.wikipedia.org/wiki/Tarjan%27s_strongly_connected_components_algorithm
Sep 03 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Reimer Behrends wrote:
 However, you could also factor out the algorithm into a class of it's own:
Yes, so instead of a nested function with everything right there next to its use, I have to go elsewhere in the file looking for a class. While this is doable, I don't think it's half as nice. I also think that trying to force something that's naturally a function that simply accesses the outer function's variables into a class with member variables that have to be copied, etc., is less desirable. I don't think you'll agree with me <g>, but take this example and rewrite it using classes: int foo(int a) { int bar(int i) { return a + 3; } return bar(3) + bar(4); } and let's compare!
Sep 03 2009
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Walter Bright (newshound1 digitalmars.com)'s article
 One could argue that gcc has them as an extension but nobody uses them.
 My experience with adding extensions to DM C++ is that nobody uses them
 because it is non-standard, not because they are a bad idea.
And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful.
Sep 03 2009
next sibling parent Mattias Holm <mattias.holm openorbit.REMOVE.THIS.org> writes:
Sean Kelly wrote:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 One could argue that gcc has them as an extension but nobody uses them.
 My experience with adding extensions to DM C++ is that nobody uses them
 because it is non-standard, not because they are a bad idea.
And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful.
Yeah, that is a problem. They did add them to GCC (not only Clang) though, and as far as using GCC extensions, most compilers adopt them one way or the other. Hopefully, they will be imported from the Apple branch of GCC to the mainline. Many things in GCC are just incredibly useful, including the vector_size attribute, and people are using them, it is not a matter of being non standard, but rather that the extensions are good enough that enough vendors implement them. I think that the blocks are crying out for standardisation, maybe not by ISO, but by some informal means between compiler vendors. / Mattias
Sep 03 2009
prev sibling parent reply Michel Fortin <michel.fortin michelf.com> writes:
On 2009-09-03 14:14:27 -0400, Sean Kelly <sean invisibleduck.org> said:

 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 One could argue that gcc has them as an extension but nobody uses them.
 My experience with adding extensions to DM C++ is that nobody uses them
 because it is non-standard, not because they are a bad idea.
And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful.
Even for OSX-specific code? I see no reason not to use them in a Cocoa app for instance, nor when you want to schedule tasks using Grand Central Dispatch. You're already bound to Apple-world anyway. -- Michel Fortin michel.fortin michelf.com http://michelf.com/
Sep 03 2009
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Michel Fortin (michel.fortin michelf.com)'s article
 On 2009-09-03 14:14:27 -0400, Sean Kelly <sean invisibleduck.org> said:
 == Quote from Walter Bright (newshound1 digitalmars.com)'s article
 One could argue that gcc has them as an extension but nobody uses them.
 My experience with adding extensions to DM C++ is that nobody uses them
 because it is non-standard, not because they are a bad idea.
And that's why I won't be using Apple's new closures, regardless of whether I'd actually find them useful.
Even for OSX-specific code?
Yup. I always write code with portability in mind, because my target platforms have a way of changing. If I were writing user-mode applications for OSX this might be different, since I'd be using Cocoa or whatever anyway, but...
 I see no reason not to use them in a Cocoa app for instance, nor when
 you want to schedule tasks using Grand Central Dispatch. You're already
 bound to Apple-world anyway.
Yeah exactly. That just isn't the realm that I work in.
Sep 03 2009
prev sibling parent Mattias Holm <mattias.holm openorbit.REMOVE.THIS.org> writes:
Walter Bright wrote:

 Nested functions do closures in a straightforward way, so by leaving off 
 nested functions they were forced to make an ugly syntax <g>. This is 
 why I shake my head in just not understanding the process that led to 
 their design.
Well, one problem would be that nested functions are already a feature in GCC, and they are not compatible (code would be broken by an introduction, at least the ABI, an ABI breaking modification of nested GCC function could have been controversial at least).
 Nested functions can usually not be called after the defining function 
 have returned. You cannot return blocks directly (since they are 
 located on the stack), but you can return a heap copy of the block.
This is handled in D automatically.
Have not looked at D's implementation of this, looks nice I think. In C this would mean stealing some extra keywords, adding _Delegate or whatever and then a file stddelegate.h that #define delegate _Delegate. Also, without forcing GC on the user, returning a delegate would be tricky to say the least (if efficiency is needed). So given the situation, they probably did a decent choice, a bit like patching an x86 CPU like AMD did for the AMD64. / Mattias
Sep 03 2009
prev sibling next sibling parent Tim M <tim.matthews7 gmail.com> writes:
S. Wrote:

 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
 
It is actually intended to be added to C which is kinda weird and against C's road map. C has decided that is a minimal abstraction over hardware to allow cross platform and not much else. C1X will probably feature barely any new features unless apple coughs up a lot of money. I don't want this in C, but it is better suited to C++ if they didn't already have this planned http://en.wikipedia.org/wiki/C%2B%2B0x#Lambda_functions_and_expressions
Sep 01 2009
prev sibling next sibling parent Michel Fortin <michel.fortin michelf.com> writes:
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/
Sep 02 2009
prev sibling parent reply 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 :)
Sep 02 2009
parent 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.
Sep 02 2009