3 ms·

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 g

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.

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.