{"id":18,"date":"2014-03-07T12:58:00","date_gmt":"2014-03-07T12:58:00","guid":{"rendered":"http:\/\/peintinger.com\/?p=18"},"modified":"2015-06-13T18:22:58","modified_gmt":"2015-06-13T18:22:58","slug":"organizing-cc-includes","status":"publish","type":"post","link":"https:\/\/peintinger.com\/?p=18","title":{"rendered":"Organizing C\/C++ includes"},"content":{"rendered":"

After starting my new job programming in a big software project I spent some thought on organizing includes and give a recommendation. Here’s what I’ve come up with. As always, some things are obvious, some are not…<\/p>\n

    \n
  1. You should only include what is necessary to compile the source code. Adding unnecessary
    \n includes means a longer compilation time, especially in large projects.<\/li>\n
  2. Each header and corresponding source file should compile cleanly on its own. That
    \nmeans, if you have a source file that includes only the corresponding header, it
    \nshould compile without errors. The header file should include not more
    \nthan what is necessary for that.<\/li>\n
  3. Try to use forward declarations as much as possible. If you’re using a
    \nclass, but the header file only deals with pointers\/references to
    \nobjects of that class, then there’s no need to include the definition of
    \n the class. That is what forward declarations are designed for!<\/p>\n

    \/\/ Forward declaration<\/p>\n

    class MyClass;<\/p>\n

    <\/p>\n<\/li>\n

  4. Note that some system headers might include others. But apart from a few
    \n exceptions, there is no requirement. So if you need both
    \n<iostream> and <string> include both, even if you can
    \ncompile only with one of them.<\/li>\n
  5. To prevent multiple-inclusions, with loops and all such attendant horrors is having an #ifndef guard.\n

    #ifndef _FOO_H
    \n#define _FOO_H
    \n  …contents of header file…
    \n#endif<\/p>\n<\/li>\n

  6. The order in which the includes appear (system includes and user includes) is up to the coding standard you follow.<\/li>\n
  7. If you have the choice of picking a coding standard regarding the order at the beginning of a new project, I recommend to go from local to global, each
    \nsubsection in alphabetical order. That way you can avoid introducing
    \nhidden dependencies. If you reverse the order and i.e. myclass.cpp
    \nincludes <string> then <myclass.h>, there is no way to catch
    \nat build time that myclass.h may itself depend on string. So if later someone includes myclass.h but does not need string, he’ll
    \nget an error that needs to be fixed either in the cpp or in the header
    \nitself. <\/li>\n
  8. So the recommended order would be:\n