source tree organization for large-scale C++ projects

[mshngo]

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

[Ian Collins]

Re: source tree organization for large-scale C++ projects

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.

[Gianni Mariani]

Re: source tree organization for large-scale C++ projects

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).

[James Kanze]

Re: source tree organization for large-scale C++ projects

On Apr 7, 2:53 am, mshngo <msh...@gmail.c omwrote:

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:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34