There's been a *lot* of speculation on this thread and very little fact.
I'd encourage everybody to play with the feature before forming
any kind of final judgement.

On Sep 3, 2009, at 8:52 PM, erik quanstrom wrote:
Did you even read the article or any of the examples? There are plenty
of things that you can "do" with blocks that you can't with just
function pointers. That's besides the fact that some of them are more
elegantly expressed with blocks that look sort of ugly with function
pointers.

on the other hand, apple says this is illegal

Where exactly does it say that?

       dispatch_block_t p;

        if(cond){
                p =^ { print("cond\n"); };
        }else{
                p =^ { print("cond\n"); };
        }
        p();

since the first part is equivalent to

        if(cond){
                struct Block _t = ...;
                p = &_t;
        }

I'm pretty sure Apple's compiler is smart enough to allow the construct that you've just mentioned. In fact, I'd be willing to bet on it. Sadly just like about anybody else on this thread I don't have an access to Snow Leopard Mac OS X at the moment. So if there needs to be an experiment run -- that'll have to
wait till next week.

intuitive?  easy to read? pretty?

What part are you complaining about? The imaginary failure?

also, if this from david's example is allowed (i'll assume
that the original examples' print(X+y) for int X and y
was a bit of a typo --- i hope!)

        block =^ (int x){ print("%d\n", x ); };

that sucker is on the stack.  by-by no-execute stack.
how does it get to the stack?  is it just copied from
the text segment or is it compiled at run time?


The structure is on the stack, the code itself is in .text as
anything else in your C program. Trust me, I've seen how
it is generated.

Thanks,
Roman.

Reply via email to