source tree organization for large-scale C++ projects

Discussion in 'C++' started by mshngo, Apr 7, 2008.

  1. mshngo

    mshngo Guest

    Hi,

    I have seen two main methods of organizing the header and source files
    in a C++ project. The first method separates the public header files
    from the remaining files (i.e., source files and internal/
    implementation header files) -- the public header files are usually
    stored in a directory named "include", and the remaining files are
    stored in another directory named "src". The structures of these two
    directories are usually closely related. For example, Postgres adopts
    this organization.

    The second method does not enforce such a separation -- files are
    placed in directories according to which software module they belong
    to, so that header files and source files belonging to the same module
    will be placed within the same directory.

    What are the trade-offs?

    Thanks!
    Mingsheng
    mshngo, Apr 7, 2008
    #1
    1. Advertising

  2. mshngo

    Ian Collins Guest

    mshngo wrote:
    > Hi,
    >
    > I have seen two main methods of organizing the header and source files
    > in a C++ project. The first method separates the public header files
    > from the remaining files (i.e., source files and internal/
    > implementation header files) -- the public header files are usually
    > stored in a directory named "include", and the remaining files are
    > stored in another directory named "src". The structures of these two
    > directories are usually closely related. For example, Postgres adopts
    > this organization.
    >
    > The second method does not enforce such a separation -- files are
    > placed in directories according to which software module they belong
    > to, so that header files and source files belonging to the same module
    > will be placed within the same directory.
    >
    > What are the trade-offs?
    >

    I've worked with both and now prefer the latter. My main reason is the
    subdirectories can map to namespaces, disambiguating files names.

    --
    Ian Collins.
    Ian Collins, Apr 7, 2008
    #2
    1. Advertising

  3. mshngo wrote:
    ....
    >
    > What are the trade-offs?


    Code modularity is sacrificed with the first method. Modularity is
    important in large projects.

    You somewhat have more work to manage the include paths, however that
    can be easily automated. I wrote MakeXS to do just that - automate as
    much of the mechanical tasks as I could - making it as easy as dropping
    in a file and typing "make".

    makexs is now available from Austria C++. http://austria.sourceforge.net/

    There are other build systems, cmake for example. MakeXS is still using
    make. (gmake to be exact).
    Gianni Mariani, Apr 7, 2008
    #3
  4. mshngo

    Craig Scott Guest

    On Apr 7, 10:53 am, mshngo <> wrote:
    > Hi,
    >
    > I have seen two main methods of organizing the header and source files
    > in a C++ project. The first method separates the public header files
    > from the remaining files (i.e., source files and internal/
    > implementation header files) -- the public header files are usually
    > stored in a directory named "include", and the remaining files are
    > stored in another directory named "src". The structures of these two
    > directories are usually closely related. For example, Postgres adopts
    > this organization.
    >
    > The second method does not enforce such a separation -- files are
    > placed in directories according to which software module they belong
    > to, so that header files and source files belonging to the same module
    > will be placed within the same directory.
    >
    > What are the trade-offs?


    We use the latter option. It makes multi-module projects easier to
    manage and allows us to keep headers in the same place as their
    contents are implemented. This is also helpful for some text editors
    which offer functionality to open an associated source/header file
    from the other, but that is a minor usability issue I guess.

    You can get some of the advantages of the former option by getting
    your build system to "install" public headers to a specific area. We
    do this so that we can test the code in a directory structure that is
    representative of where the files will be when installed proper. Only
    the root of the directory structure changes. This has been a gain for
    development since the debug/testing environment is closer to the final
    product.

    --
    Computational Modeling, CSIRO (CMIS)
    Melbourne, Australia
    Craig Scott, Apr 7, 2008
    #4
  5. mshngo

    James Kanze Guest

    On Apr 7, 2:53 am, mshngo <> wrote:

    > I have seen two main methods of organizing the header and
    > source files in a C++ project. The first method separates the
    > public header files from the remaining files (i.e., source
    > files and internal/ implementation header files) -- the public
    > header files are usually stored in a directory named
    > "include", and the remaining files are stored in another
    > directory named "src". The structures of these two directories
    > are usually closely related. For example, Postgres adopts this
    > organization.


    > The second method does not enforce such a separation -- files
    > are placed in directories according to which software module
    > they belong to, so that header files and source files
    > belonging to the same module will be placed within the same
    > directory.


    > What are the trade-offs?


    I presume you're referring to the development code; in delivered
    code, the headers are almost always in a separate directory from
    the sources, since the sources aren't part of the base
    deliverables, and the headers are. (Even if your project is
    open source, you don't want users to have to -I on your source
    directories---or at least, the users won't want to.) This
    argues somewhat for a separation during development as well;
    ensure that you're not accidentally including a header which
    won't be delivered when you compile your tests, for example.
    And having less files in the directories may also improve search
    times for the compilers. But such differences are probably
    very minor.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Apr 7, 2008
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Steven T. Hatton
    Replies:
    7
    Views:
    416
    Steven T. Hatton
    Apr 7, 2004
  2. Eric
    Replies:
    0
    Views:
    297
  3. Stub

    B tree, B+ tree and B* tree

    Stub, Nov 12, 2003, in forum: C Programming
    Replies:
    3
    Views:
    10,109
  4. limor
    Replies:
    9
    Views:
    519
    A. Lloyd Flanagan
    Apr 23, 2004
  5. Simon COURTOIS

    Ruby projects code organization

    Simon COURTOIS, Aug 13, 2008, in forum: Ruby
    Replies:
    4
    Views:
    170
    elliottcable
    Aug 14, 2008
Loading...

Share This Page