4 ms·

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 o

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 12y 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.
- mtdewcmu 12y ago
  Yeah. C is a boring language that barely ever changes. But I'm not sure there isn't wisdom in being dull.
  - nitrogen 12y ago
    Compound literals in C are awesome like it's 1999: Assuming you have this: struct point { float x, y, z; }; void do_something_with_point(struct point *p); You can do this: do_something_with_point(&(struct point){.x = 1.5, .y = 1.5, .z = 3.5});
    - mtdewcmu 12y ago
      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.
      - nitrogen 12y ago
        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.
        mtdewcmu 12y ago
        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.
        nitrogen 12y ago
        It can be useful for an API that expects pointers for whatever reason.
nitrogen 12y 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.
- mtdewcmu 12y ago
  Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.
  - nitrogen 12y ago
    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.
    - mtdewcmu 12y ago
      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 its spare syntax and the fact that there is almost no room for ambiguity and subtle, invisible side effects. What you see is what you get. 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?

raverbashing 12y 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.

mtdewcmu 12y ago
Yeah. C is a boring language that barely ever changes. But I'm not sure there isn't wisdom in being dull.
- nitrogen 12y ago
  Compound literals in C are awesome like it's 1999: Assuming you have this: struct point { float x, y, z; }; void do_something_with_point(struct point *p); You can do this: do_something_with_point(&(struct point){.x = 1.5, .y = 1.5, .z = 3.5});
  - mtdewcmu 12y ago
    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.
    - nitrogen 12y ago
      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.
      - mtdewcmu 12y ago
        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.
        nitrogen 12y ago
        It can be useful for an API that expects pointers for whatever reason.

nitrogen 12y 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.

mtdewcmu 12y ago
Callbacks are inherently going to make a program harder to follow. Without seeing the code, it's hard to suggest other solutions.
- nitrogen 12y ago
  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.
  - mtdewcmu 12y ago
    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 its spare syntax and the fact that there is almost no room for ambiguity and subtle, invisible side effects. What you see is what you get. 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?