3 ms·
> 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 wo
by 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 agoIt'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 agoGood 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.