3 ms·

Because then people know what they are using. And that is more valuable then fixing simple compiler errors. I'v seen programs that have an "uberinclude", usual

by gens 10y ago

Because then people know what they are using. And that is more valuable then fixing simple compiler errors. I'v seen programs that have an "uberinclude", usually named "common.h" or something like that, that includes not only standard libs but also other headers. It is horrible. There is no way to understand what code written with that mind-set is doing, other then slaving over a notebook trying to make sense of it. Granted all encompassing/nested headers don't mean unreadable code. But from my experience with my own code, clear and separate headers (including standard ones) make me write clear and separate .c files.

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 ago
    Do 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 ago
      Having 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)

by gens 10y ago

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 ago
  Do 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 ago
    Having 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)