Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anonymous functions in C

github.com

Post reply on HN
Print view View original

41–50 of 51 posts

Re: Anonymous functions in C

#41

Post by mtdewcmu »

billsix wrote: post #34
mtdewcmu wrote: post #23

Earlier quoted context omitted.

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.

The question to which I responded did not inquire about performance nor about portability http://tirania.org/blog/archive/2011/Feb-17.html

My comment was about GCC's local functions. It wasn't really about your comment, so I regret if you took it personally.

Re: Anonymous functions in C

#42

Post by mtdewcmu »

graphitemaster wrote: post #38
fyolnish wrote: post #36

Earlier quoted context omitted.

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

Correct, the problem is to call the function you cannot treat it as a standard function since it's pointing to a struct, the struct does contain the actual function pointer but there is an implicit `this' first argument to that function pointer which has to be that struct itself. This means you cannot use the block in an API that explicitly requires a function pointer, instead the API must specifically be aware of th…

It sounds like you could say it's ObjectiveC-compatible, not ObjectiveC per se. But it's an unimportant distinction.

Re: Anonymous functions in C

#43

Post by mtdewcmu »

nitrogen wrote: post #29
mtdewcmu wrote: post #11

Earlier quoted context omitted.

You can take the address of a literal? 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.

Yes, you can. You can use it to create an approximation of named parameters, because struct members that don't have an initializer will default to zero. It's still not nearly as compact as, say, Ruby, but for C it's pretty awesome and fast.

That's interesting. You know you can pass structs by value, too, so I'm not sure how necessary it is to take the address.

Re: Anonymous functions in C

#44

Post by e12e »

mtdewcmu wrote: post #20
Moto7451 wrote: post #18

Earlier quoted context omitted.

Nope, clang can be used on BSD, Linux, and Windows as well. http://clang.llvm.org/get_started.html

I'm aware of that, but do you get blocks?

Eg on Debian: apt-get install libblocksruntime0 libblocksruntime-dev

http://compiler-rt.llvm.org/

Re: Anonymous functions in C

#45

Post by fyolnish »

graphitemaster wrote: post #38
fyolnish wrote: post #36

Earlier quoted context omitted.

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

Correct, the problem is to call the function you cannot treat it as a standard function since it's pointing to a struct, the struct does contain the actual function pointer but there is an implicit `this' first argument to that function pointer which has to be that struct itself. This means you cannot use the block in an API that explicitly requires a function pointer, instead the API must specifically be aware of th…

Of course, there's no way around that except to write block variants for those functions. stdlib on osx for example has block variants of most functions that take function pointers (`man qsort_b` for an example)

But if you write your program to use blocks from the start, that's not a big problem.

Re: Anonymous functions in C

#46

Post by nitrogen »

mtdewcmu wrote: post #43
nitrogen wrote: post #29

Earlier quoted context omitted.

Yes, you can. You can use it to create an approximation of named parameters, because struct members that don't have an initializer will default to zero. It's still not nearly as compact as, say, Ruby, but for C it's pretty awesome and fast.

That's interesting. You know you can pass structs by value, too, so I'm not sure how necessary it is to take the address.

It can be useful for an API that expects pointers for whatever reason.

Re: Anonymous functions in C

#47

Post by nitrogen »

mtdewcmu wrote: post #40
nitrogen wrote: post #30

Earlier quoted context omitted.

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.

I'm sure that there are a lot of cases where you could make code look neater and sleeker with this kind of syntax extension, but my thesis -- and this is inherently hard to prove -- is that the uglier code you may have to write in C is nonetheless more robust and maintainable code in the end. A lot of very good software has been written in C, and what I suspect contributes to C's impressive record of robustness is it…

...almost no room for ambiguity and subtle, invisible side effects. What you see is what you get. [emphasis mine]

The key word there is "almost." C does have lots of undefined behaviors.

Re: Anonymous functions in C

#48

Post by binarycrusader »

nitrogen wrote: post #31
binarycrusader wrote: post #28

Earlier quoted context omitted.

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)

That page does mention Linux in one section: https://en.wikipedia.org/wiki/Blocks_%28C_language_extension...

That's really annoying; the headline claims one thing and the later text clearly contradicts.

Regardless, both of you appear to be correct:

  BlocksRuntime - a target-independent implementation of
  Apple "Blocks" runtime interfaces.
http://compiler-rt.llvm.org/

Re: Anonymous functions in C

#49

Post by malkia »

graphitemaster wrote: post #35
malkia wrote: post #33

Wondering how a debugger would react to this code?

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 debu…

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

Re: Anonymous functions in C

#50

Post by mtdewcmu »

nitrogen wrote: post #47
mtdewcmu wrote: post #40

Earlier quoted context omitted.

I'm sure that there are a lot of cases where you could make code look neater and sleeker with this kind of syntax extension, but my thesis -- and this is inherently hard to prove -- is that the uglier code you may have to write in C is nonetheless more robust and maintainable code in the end. A lot of very good software has been written in C, and what I suspect contributes to C's impressive record of robustness is it…

... almost no room for ambiguity and subtle, invisible side effects. What you see is what you get. [emphasis mine] The key word there is "almost." C does have lots of undefined behaviors.

If you don't hedge your statements about programming, you will invariably be wrong. There are always counter-examples.

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.

Post reply on HN