4 ms·

"It’s a mistake to use typedef for structures and pointers." C programmers tend to forget this wise recommendation.

by etqwzutewzu 9y ago

Ace17 9y ago
I have always though it was good practise (because it reduces the verbosity) ; Could you please prove me wrong? :-)
- luckydude 9y ago
  The only thing I can think of is that you could have int mytype; conflicting with typedef struct { ... } mytype; By putting the "struct" in front you only potentially conflict with other struct definitions. Is that the thinking or is it something else?
- etqwzutewzu 9y ago
  Yes, for pointer types for example type qualifiers (e.g., const or volatile) cannot penetrate typedef of pointer types. So if you use typedef with pointers you are stuck.
- dllthomas 9y ago
  It varies a bit by context; Linus's call is likely the right one in the context of the kernel, though to be sure it's not so big a deal that other approaches can't be made to work fine. You call out one upside - decreased verbosity. The accompanying downside is usually - as in this case, for both structs and pointers - that potentially relevant information is made less visible. Whether it's a good idea depends on how likely that information is to be actually relevant, weighed against the upsides. Where performance is relevant, you want to be aware of where you're potentially passing large structs around. Putting this info in the type name instead is an option (eg _s), and can reduce verbosity a bit. I don't know of any good reasons to call out structs that are sized like primitives. The case against hiding pointers is much stronger. Level of indirection can be relevant to performance, and is often relevant to correctness, particularly where mutation is involved. You can put it in the type name, but it's not going to be any less verbose - a star is already one character. I allow a possible exception here for where an opaque type is allocated by a library and passed around as a handle and the client really doesn't need to ever know whether it's a pointer or an int index or what.

"It’s a mistake to use typedef for structures and pointers." C programmers tend to forget this wise recommendation.

Ace17 9y ago

I have always though it was good practise (because it reduces the verbosity) ; Could you please prove me wrong? :-)

luckydude 9y ago
The only thing I can think of is that you could have int mytype; conflicting with typedef struct { ... } mytype; By putting the "struct" in front you only potentially conflict with other struct definitions. Is that the thinking or is it something else?
etqwzutewzu 9y ago
Yes, for pointer types for example type qualifiers (e.g., const or volatile) cannot penetrate typedef of pointer types. So if you use typedef with pointers you are stuck.
dllthomas 9y ago
It varies a bit by context; Linus's call is likely the right one in the context of the kernel, though to be sure it's not so big a deal that other approaches can't be made to work fine. You call out one upside - decreased verbosity. The accompanying downside is usually - as in this case, for both structs and pointers - that potentially relevant information is made less visible. Whether it's a good idea depends on how likely that information is to be actually relevant, weighed against the upsides. Where performance is relevant, you want to be aware of where you're potentially passing large structs around. Putting this info in the type name instead is an option (eg _s), and can reduce verbosity a bit. I don't know of any good reasons to call out structs that are sized like primitives. The case against hiding pointers is much stronger. Level of indirection can be relevant to performance, and is often relevant to correctness, particularly where mutation is involved. You can put it in the type name, but it's not going to be any less verbose - a star is already one character. I allow a possible exception here for where an opaque type is allocated by a library and passed around as a handle and the client really doesn't need to ever know whether it's a pointer or an int index or what.