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!

== 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.

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

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

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/

== 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.