Anonymous functions in C(github.com) |
Anonymous functions in C(github.com) |
C++ in fact is only usable (in a team) if its features are pruned and limited in a team. Really
Throw in some fine preprocessor magic and you'll end up with completely unmaintanable and impossible to understand code.
GCC supports it http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
I would argue the opposite: these things are actually way more useful than they seem at first. The fewer things the language makes you think about, the more you can focus on what you're trying to actually do.
[0] http://en.wikipedia.org/wiki/Blocks_(C_language_extension)
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.
Similar problem is with say Qt's generated moc_Xxx source, Ui_xxx source, etc. files - unless you make the effort of storing these generated files somewhere you might have problems debugger later.
This is in general my "arrgh" against code generation, and "aargh" is not against it - it's simply when you had forgot to keep the files somewhere and the crashdump snaps fingers at you...
Some high praise, that. C++ closures: they're not that awful.
If you want a language with closures, and all you have is C, the time-honored solution is to write an interpreter and give the interpreted language closures. That is a good way to go.
Assuming you have this:
struct point {
float x, y, z;
};
void do_something_with_point(struct point *p);
do_something_with_point(&(struct point){.x = 1.5, .y = 1.5, .z = 3.5});Being able to specify a literal for a struct is useful. You can, for instance, put the literal in a macro and use the macro to initialize or reset a struct. It's better than having to write additional functions to do something trivial.
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?
The key word there is "almost." C does have lots of undefined behaviors.
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]
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
Regardless, both of you appear to be correct:
BlocksRuntime - a target-independent implementation of
Apple "Blocks" runtime interfaces.
But if you write your program to use blocks from the start, that's not a big problem.
The kind of ambiguity and side-effects I'm alluding to are ones programming languages explicitly support and encourage, like overloaded operators and overloaded methods in C++. In C, the effects of a segment of code are comparatively predictable just by looking at the code itself. In quite a large number of languages, you can't draw many conclusions about what a segment of code does without looking in multiple other places.