31–40 of 51 posts
Earlier quoted context omitted.
I'm aware of that, but do you get blocks?
Indeed, I don't think you do: Blocks are supported for programs developed for Mac OS X 10.6+ and iOS 4.0+,[1] although third-party runtimes allow use on Mac OS X 10.5 and iOS 2.2+.[2] http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
Earlier quoted context omitted.
The problem with clang blocks is they're represented as a Objective-C object, this makes them unusable in APIs that expect a function pointer, the only way you can cast them to a function pointer is to define the structure which represents the block and mmap executable code pages to marshal the call. Such a library exists that binds them to libffi here https://github.com/mikeash/MABlockClosure This feat alone makes b…
I don't think they could be an ObjectiveC object, because they're described as C, not ObjectiveC. I think the problems you're describing are ones that are going to be faced in any attempt at C closures. Closures have memory attached, that's the appeal of them and also the source of all the problems.
Earlier quoted context omitted.
As long as the stack frame is still active, the local variables are still alive and valid. So you could pass a local function as a parameter, but you could not return it. I think jwz called these "downward funargs". GCC supports it http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
GCC's nested functions are implemented with trampolines, so there will be a performance penalty. For the amount that you gain, they seem like a bad idea. Tying your code to GCC for the sake of a small amount of convenience is a bad idea.
Wondering how a debugger would react to this code?
Earlier quoted context omitted.
I don't think they could be an ObjectiveC object, because they're described as C, not ObjectiveC. I think the problems you're describing are ones that are going to be faced in any attempt at C closures. Closures have memory attached, that's the appeal of them and also the source of all the problems.
Nope, they're an ObjectiveC object with some specialties at the compiler level. Google how they're implemented.
Block_copy etc are implemented in libclosure which iirc does not require libobjc either. But of course if you ARE writing objc, they are valid objects and can be treated as such
Earlier quoted context omitted.
I'm aware of that, but do you get blocks?
Indeed, I don't think you do: Blocks are supported for programs developed for Mac OS X 10.6+ and iOS 4.0+,[1] although third-party runtimes allow use on Mac OS X 10.5 and iOS 2.2+.[2] http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
Earlier quoted context omitted.
Nope, they're an ObjectiveC object with some specialties at the compiler level. Google how they're implemented.
An objective-c object is just a pointer to a struct. You don't need the objective-c runtime to call a block. Block_copy etc are implemented in libclosure which iirc does not require libobjc either. But of course if you ARE writing objc, they are valid objects and can be treated as such
Earlier quoted context omitted.
As long as the stack frame is still active, the local variables are still alive and valid. So you could pass a local function as a parameter, but you could not return it. I think jwz called these "downward funargs". GCC supports it http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
GCC's nested functions are implemented with trampolines, so there will be a performance penalty. For the amount that you gain, they seem like a bad idea. Tying your code to GCC for the sake of a small amount of convenience is a bad idea.
Earlier quoted context omitted.
Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.
Some possible examples include qsort() and iterators. You could also use them for event handlers, but those are probably clearer as separate methods. I haven't used LambdaPP, but I'm guessing you can get around the lack of closures the same way you do with callbacks, by passing a void* with necessary data.
Adding simple, inline anonymous functions like these is a fairly modest proposal, of course, and I can't tell you exactly what damage they'd cause. They could turn out harmless. But they are redundant, because C already has a syntax for functions, and that redundancy now forces the programmer to have to make a choice about which syntax to use every time the situation permits them. Reading code becomes a bit more complicated, because there are more kinds of syntactic elements to recognize and know the consequences of. You end up splitting your time between two ways of writing functions, and that works against developing consistent practices and conventions for writing functions.
Is there a trade-off? Probably. It may be too onerous to write some types of code in C, and a little syntactic sugar might be able to make it tractable. But maybe you're better off writing that code in a different language, anyway. C has a good thing going, so why risk messing with it?