3 ms·

How is it hidden? Can't the inquiring mind simply examine the codebase to see it's a struct? And if they choose not to, isn't it on them if it turns out to be s

How is it hidden? Can't the inquiring mind simply examine the codebase to see it's a struct? And if they choose not to, isn't it on them if it turns out to be something other than what they assumed it was without looking?

moloch-hai 4y ago
It is hidden because you have to "examine" somewhere else before you know. But it doesn't matter, because you don't need to know unless it is subject to invisible implicit conversions. What might you do differently, having "examined" the typedef?
- Warwolt 4y ago
  I understand the preference for keeping the struct tag, but virtually no other language does this, with modern IDEs it's trivial to find out what the definition of a given type is, so the tag seems superfluous to me in practice.
  - Jtsummers 4y ago
    We don't even need modern IDEs. ctags solved this problem last century.
rm445 4y ago
I think so. Even with a compiled library distributed with a header file but no source, the header file needs to forward declare something like 'typedef struct foo FOO;' So (unless there's some clever trick I've missed) you can always tell it's a struct but not necessarily see the definition. There is a point, perhaps a little specious, that you put a module's data structures behind a typedef so the interface doesn't change if it changes from a simple data type to a struct. Probably doesn't happen too often. The perfect C object-oriented-style interface is FILE* from stdio.h. A FILE is a structure full of operating-system-specific file information but you never have to see it or worry about what's in it, you just use the functions.
- heywhatupboys 4y ago
  > There is a point, perhaps a little specious, that you put a module's data structures behind a typedef so the interface doesn't change if it changes from a simple data type to a struct. Probably doesn't happen too often. you could never do this in C. If it is a "value type" i.e. a non-pointer, then you cannot change the size of the value, without changing the ABI and the function decl.

moloch-hai 4y ago

It is hidden because you have to "examine" somewhere else before you know. But it doesn't matter, because you don't need to know unless it is subject to invisible implicit conversions. What might you do differently, having "examined" the typedef?

Warwolt 4y ago
I understand the preference for keeping the struct tag, but virtually no other language does this, with modern IDEs it's trivial to find out what the definition of a given type is, so the tag seems superfluous to me in practice.
- Jtsummers 4y ago
  We don't even need modern IDEs. ctags solved this problem last century.

rm445 4y ago

I think so. Even with a compiled library distributed with a header file but no source, the header file needs to forward declare something like 'typedef struct foo FOO;' So (unless there's some clever trick I've missed) you can always tell it's a struct but not necessarily see the definition. There is a point, perhaps a little specious, that you put a module's data structures behind a typedef so the interface doesn't change if it changes from a simple data type to a struct. Probably doesn't happen too often. The perfect C object-oriented-style interface is FILE* from stdio.h. A FILE is a structure full of operating-system-specific file information but you never have to see it or worry about what's in it, you just use the functions.

heywhatupboys 4y ago
> There is a point, perhaps a little specious, that you put a module's data structures behind a typedef so the interface doesn't change if it changes from a simple data type to a struct. Probably doesn't happen too often. you could never do this in C. If it is a "value type" i.e. a non-pointer, then you cannot change the size of the value, without changing the ABI and the function decl.