5 ms·

>Rule 5. Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self­evident. Data struct

• planteen 10y ago
  >>Simple rule: include files should never include include files. > Yes, please! Let's say I have a C++ class defined in a header that uses std::string. So I require that anyone who uses my header already has <string> included in version 1.0.0. Then, in version 1.1.0, I added to the class in the header so that now it requires std::map. If the caller doesn't have <map> included, there will now be a compilation error! How is that better than simply including string and map in the class header itself?
  • 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)
• kbob 10y ago
  >Simple rule: include files should never include include files. For small programs, that's a good rule* . For larger code bodies, it's counterproductive. If my module uses foo, there's no reason for my module to know that foo depends on bar. If the next version of foo drops its bar dependency and now uses baz which also requires fat, foo's clients shouldn't have to be rewritten. You can ameliorate the breakage sometimes by keeping dependencies out of header files (and that's generally a good idea), but sometimes you can't. My personal rule is exactly the opposite: every header should compile with no prerequisites. For that reason, the vast majority of my foo.h files are included as the very first line of foo.c. If foo.c doesn't compile, I know to fix foo.h. Pike's concern that lexical analysis is the most expensive compiler phase is way out of date. * In 1989, there were no large programs. (-: