Anonymous functions in C

https://github.com/graphitemaster/lambdapp

by C-- • 12 years ago

46 50 12 years ago

mtdewcmu16• 12 years ago

This is basically a way of obfuscating your C code. If you want to write obfuscated code, C++ has extensive support for this. I think it's actually a strength of C to not have many features. It ultimately makes code more readable and reliable.

raverbashing• 12 years ago

I don't think I can agree more with your comment.

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.

mtdewcmu16• 12 years ago

Yeah. C is a boring language that barely ever changes. But I'm not sure there isn't wisdom in being dull.

nitrogen7• 12 years ago

Anonymous functions are a way of de-obfuscating code that is heavy in callbacks. Instead of having the logic flow indirectly to some external method that might be far away, the logic can live within one function body.

mtdewcmu16• 12 years ago

Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.

overgard4• 12 years ago

That's neat, but without closures I don't really see how you could do much with it outside of toy examples. Going off the examples -- how often do you write something like a foreach or a map or reduce that doesn't reference its enclosing scope?

graphitemaster6• 12 years ago

If you look at Redroid (a project which makes extensive use of lambdapp) you'll see how map/list/etc can take advantage of this https://github.com/graphitemaster/redroid hashtable.c and list.c look for [hashtable|list]_foreach. Another good example is config_save in config.c.

anaphor• 12 years ago

You could do closure conversion, but then you run into problems with the lifetimes of things, oh and then you're basically reimplementing lisp.

overgard4• 12 years ago

Not really; C++ now has closures and I'm not going to say it's ideal, but it's not that awful either. The whole "reinventing lisp" argument really only applies to macros at this point (ie: something that fundamentally would require a Lisp to do properly), the other features have been scavenged by other languages without being a lisp just fine.

ufo• 12 years ago

You wouldn't need full blown closures. Inner procedures that can't escape their scope, like they had in Pascal are already useful but don't come with the extra memory management requirements of closures.

overgard4• 12 years ago

Yeah, those would be nice to have in C.

mtdewcmu16• 12 years ago

A closure is syntactic sugar for a function plus a struct. Sometimes I think they would be a useful addition to C. But these kinds of things never turn out to be as useful as they seem at first.

overgard4• 12 years ago

That's true in a hand-wavey sense, but it ignores that function+struct means you have to define new types, include those types everywhere your closure is used, manage the lifetime and scope of those types, etc. etc.

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.

billsix3• 12 years ago

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

mtdewcmu16• 12 years ago

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.

yason• 12 years ago

Anonymous (or inner) functions aren't really valuable per se but syntactic sugar for writing the code into a static function somewhere in the same file: closures give anonymous (or inner) functions the power which is what makes them useful.

misframer• 12 years ago

If you use clang, blocks are another approach.

[0] http://en.wikipedia.org/wiki/Blocks_(C_language_extension)

[1] http://clang.llvm.org/docs/BlockLanguageSpec.html

mtdewcmu16• 12 years ago

I thought those were only available on OSX and iOS.

Moto7451• 12 years ago

Nope, clang can be used on BSD, Linux, and Windows as well.

http://clang.llvm.org/get_started.html

graphitemaster6• 12 years ago

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 blocks essentially useless unless your entire API is also block-based, as in T (^foo)(...) vs T(*foo)(...).

mtdewcmu16• 12 years ago

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.

malkia2• 12 years ago

Wondering how a debugger would react to this code?

graphitemaster6• 12 years ago

Lambdapp inserts #line directives into the source code, compilers are required to respect those directives and utilize them when producing debug sections in the binary. For instance in the case of gcc/clang on *nix the compiler will produce .debug_line sections as part of the DWARF debug format. Debuggers like gdb and even valgrind utilize this information to provide correct output. So to answer your question, a debugger would react to this code exactly how it should react, as if the lambda was called via a function and the file / line should be correct.

malkia2• 12 years ago

I'm more asking as in debugger integration with versioning system (p4, git, etc.) - Say you've got a crashdump, and was able to track it down to some specific source code release - now you should've also saved the intermediate generated files somewhere - but this means that these might have to go back in p4/git/svn/etc. or find alternative place for them... Generating them again won't be the same.

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

Anonymous functions in C

Related Stories