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.
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});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.
GCC supports it http://gcc.gnu.org/onlinedocs/gcc/Nested-Functions.html
Some high praise, that. C++ closures: they're not that awful.
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.
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.
[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...