views:

76

answers:

1

I want to reorganize my C++ code project, which contains of hundreds of source files.

I want to split everything into 4 libraries, taking care to avoid cyclic dependencies:

(a) src/core
(b) src/util
(c) src/create
(d) src/process

Basically, core implements the basic data structures and util implements some basic utility functions to work with them.

create uses (a) and (b) to create such data structures from data, which is a kind of complicated procedure, and process takes such such data structures and processes them, implementing the main functionality of the package.

Is that reasonable?

I also have some additional code: There are some functions that glue other stuff together, e.g. they create the data structures from data in a particular way and then process them. Also, there are different user programs containing main.

I'm thinking of putting them into different directories:

src/glue - for the glue code that uses the `create` and `process` libraries
src/driver - for the code with main() functions

Is that overkill? Any suggestions?

I notice it's not an essential programming question, but I'd like some advice before I reorganize everything and publish the code.

Thanks!

+2  A: 

In general, I think what you've outlined is reasonable. I usually try to create a Core library that contains the data structures and functionality that is used by the other projects within my solution. This is an ongoing process. As new functionality and data structures are added, I look for ways to abstract them so that I can rightfully include them in the Core library.

That said, one of the biggest considerations in laying out your C++ code is minimizing compilation time. For example, use forward declarations as much as possible in your header files. Also, within a given header file, only include those headers that are absolutely necessary, reserving the bulk of the headers for inclusion in the .cpp files.

Another thing to get in the practice of is using namespaces to segregate your library code. I doubt you'll run into naming conflicts within your project, but it is still a good habit to get into.

Matt Davis