10 ms·

Just use the typedef. Even if you personally find the other variants readable, chances are that your peer reading your code doesn't.

• 2trill2spill 10y ago
  No don't use typedefs there's no real reason[1] and it may cause problems. Also if your peer can't read a function pointer I don't know what help you plan on getting from them anyway, chances are you are helping/teaching them, not the other way around. [1]: http://yarchive.net/comp/linux/typedefs.html http://yarchive.net/comp/linux/typedefs.html
  • moron4hire 10y ago
    Just because Linus Torvalds is a successful programmer doesn't mean he is at all correct about issues of programming. The vast majority of any of the opinions I've seen him express on programming fly in the face of good engineering practice under some guise of "real, macho programmers don't need tools". I'm not afraid to admit: I need tools. I need lots and lots of tools to do my job. The more the computer can be used to make my job easier, the better. There is no virtue in hard work for hard work's sake.
    • 2trill2spill 10y ago
      > Just because Linus Torvalds is a successful programmer doesn't mean he is at all correct about issues of programming. The vast majority of any of the opinions I've seen him express on programming fly in the face of good engineering practice under some guise of "real, macho programmers don't need tools". Is he wrong in this instance or our you going to ignore his point because he's not always right? > I'm not afraid to admit: I need tools. I need lots and lots of tools to do my job. The more the computer can be used to make my job easier, the better. There is no virtue in hard work for hard work's sake. So, as a C programmer I use lot's and lot's of tools. But that doesn't change the point that many view typedefs as bad practice[1]. [1]: http://stackoverflow.com/questions/3781932/is-typedefing-a-pointer-type-considered-bad-practice http://stackoverflow.com/questions/3781932/is-typedefing-a-p...
  • kllrnohj 10y ago
    That post does not say "don't use typedefs there's no real reason." It says "don't use typedefs without a real reason." Linus even provides a few examples of good uses of typedefs. Specifically he's talking about typedef'ing structs to a named type to hide that it's a struct. That's different from typedef'ing a function pointer so that you don't need to be a C parsing expert to read the code.
    • 2trill2spill 10y ago
      > That's different from typedef'ing a function pointer so that you don't need to be a C parsing expert to read the code. If you can't read C code you should work on your C programming ability, there is nothing difficult about reading function pointers. Edit: If people are getting tripped up with basic syntax good luck with the actual hard parts of C, Like lack of memory safety, concurrent memory management, undefined behavior, etc.
      • Spivak 10y ago
        It's not just about readability, it's about making a contract with the user. If you typedef a complex struct in your library you're telling your users to treat this type like it's a black-box and not look inside because the next version of the library might contain something different and your code will break if you depend on it.
        • 2trill2spill 10y ago
          > It's not just about readability, it's about making a contract with the user. If you typedef a complex struct in your library you're telling your users to treat this type like it's a black-box and not look inside because the next version of the library might contain something different and your code will break if you depend on it. No need to use typedef, just use an opaque struct if you want something to behave like a blackbox.
      • kllrnohj 10y ago
        Good luck parsing this: double (*my_function(int(*callback)(void*)))(double); without needing to think way harder on it than if typedefs were used: func2* my_function(func1*) This isn't basic syntax. C's parser is really bloody complex. That's why we have things like ioccc.org, because C's syntax is NOT trivial.
  • keithnz 10y ago
    thing is, in practice it gets used as a type. If you repeat that function definition more than once you are creating a bit of a nightmare to maintain. For instance if you need to add an extra parameter, you can easily find all usages. If something else uses the same definition, but is used for a different purpose, it gets much harder to distinguish the different usages. especially for a good ol void (callback)(void context) which a number of event's may use, and then later some may callback with more information which can be changed in once place and the compiler will quickly show you what breaks.
  • icebraining 10y ago
    Most of those are against typedefs for structs, and in the last message, he says that using a typedef for a complex function pointer is "just common sense".
  • jhomedall 10y ago
    Linus directly contradicts you in that linked thread, for this specific situation: And as mentioned, there _are_ exceptions. Some types just get _sooo_ complex that it's inconvenient to type them out, even if they are perfectly regular types, and don't depend on any config option. The "filldir_t" typedef in fs.h is such an example - it's not really opaque, _nor_ is it a config option, but it sure as hell would be inconvenient for all low-level filesystems to do int my_readdir(struct file *filp, void *dirent, int (*filldir)(void *, const char *, int, loff_t, u64, unsigned)) { ... } because let's face it, having to write out that "filldir" type just made me use two lines (and potential for totally unnecessary tupos) because the thing was so complex. So at that point, using a typedef is just common sense, and we can do int my_readdir(struct file *filp, void *dirent, filldir_t filldir) { ... } instead. But it's really quite hard to make that kind of complex type in C. It's almost always a function pointer that takes complex arguments.
• DSMan195276 10y ago
  Personally I don't like when people hide a pointer behind a typedef. If you want to use a typedef, typedef the function and then declare a pointer to that: typedef int func(void); func *func_ptr; Avoids the mess of the function pointer syntax, but still makes the fact that it is a pointer clear.
  • scivey7 10y ago
    It's never even occurred to me to typedef a function like this, and now that I think about it I'm not sure why. Your way is a lot clearer. Thanks for the tip. Do you remember where you picked this up? Any particular book or codebase?
    • DSMan195276 10y ago
      I picked it up just reading various C stuff on the internet - I think this one actually came from a Reddit user. It's not a use-case I think I've ever seen used anywhere, except for my personal code. Even then though, I admittedly almost always just type out the regular function-pointer syntax, since I find that function-pointers for me almost always just get declared in one location anyway.
  • lomnakkus 10y ago
    Correct me if I'm wrong, but isn't a "function" always a pointer in C? That is, there's no such thing as a "value function" in C, right? Given that, what's the advantage for "your version" of the idiom? (This may just be nitpicking.)
    • has2k1 10y ago
      Yes. Once declared, function pointers are similar to regular functions. They both point to a value that cannot be changed. That value is a block of code.
    • tropo 10y ago
      No, but C will automatically take the address. The same goes for arrays. You can explicitly take the address of a function, and this is different from taking the address of a function pointer. Pros: beginner confusion; sometimes bugs. Cons: one less character to type; sometimes able to get more out of a macro
• bjackman 10y ago
  I agree that typedefs are clearer for this but usually you don't have a choice and neither does the reviewer. E.g. coding style for Linux essentially says no typedefs. On the upside I have worked on projects were it's required.
• userbinator 10y ago
  You still need to know how to write the typedef.