3 ms·
Yeah I agree splitting functionality into separate headers is a good idea. But I feel like the rule "don't include headers in headers" is good advice in lots of
by planteen 10y ago
Yeah I agree splitting functionality into separate headers is a good idea. But I feel like the rule "don't include headers in headers" is good advice in lots of situations.
Redis is often thrown around as an example of an excellent, clean C source code base. Look at server.h. It has 34 include statements. Would you rather that every C file that includes server.h have to include these 34 files before including server.h? Seems insane to me.
https://github.com/antirez/redis/blob/unstable/src/server.h https://github.com/antirez/redis/blob/unstable/src/server.h
- gens 10y ago>Redis is often thrown around as an example of an excellent, clean C source code base. Look at server.h. It has 34 include statements. Would you rather that every C file that includes server.h have to include these 34 files before including server.h? Seems insane to me. Good point. This is exactly why I would want that, yes.
- planteen 10y agoDo you know of a large C (or C++) open source project that follows the rule of no headers included in headers? I'd like to take a peek at its source.
- gens 10y agoHaving looked around, no. LibPNG seems to keep it at a minimum, though. Guess i'm the only one doing that. (and i have no problems)