src/ folder structure in C++?

问题

i'm coming into C++ from Java/AS3-land, and i'm used to the package-cum-folder structure for my classes. and i like it.

i understand the very basics of namespaces in c++, and i'm happy to leave it at just the basics. but, as my project gets more complex, i'd like to keep my folder structure organized in a way i can keep in my head. i.e. something similar to Java/AS3.

1) is there any reason to not have a folder structure like:

src/
 model/
 view/
 controller/

possibly with subfolders? (this is just an MVC example, the folder structure could be whatever depending on the project's needs.) it just seems unruly to have a src/ folder with a huge pile of header and source files within.

2) if the answer to 1) could be "go ahead and do what you want", would it be unwise/unnecessary to create a namespace for each folder, similar to Java/AS3's way of creating a package for each folder? my understanding is that namespaces are not usually used like this, nested deeply and folder-related.

回答1:

I've always liked the namespace for each folder. Mostly because when I have to maintain somebody else's code, the namespace helps me find where the class was originally defined.

Well named header files can also help with this though. I also wouldn't suggest going more than 2-3 namespaces, as then it just becomes obnoxious. You'll find yourself using "using namespace blah;" a lot which I always find to be a red flag for C++ code. And you can't use "using namespace" inside a header file without some severe problems occurring.

It's all completely optional though in C++.

回答2:

You may want to have a look at John Lakos Large-Scale C++ Software Design. Basically, you can do that, but your packages should (as in Java) have an acyclic dependency graph. Also, it may be opportune for each package to document which headers are exported and which aren't, maybe like so:

src/
 |- package1/
     |- exported_symbols_1.hh
     |- exported_symbols_2.hh
     |- src/
         |- impl_1.hh
         |- impl_1.cc
 |- package2/
     |- sub_package_2_1/
         |-  exported.hh
         |-  src/
                 ...
      |- src/
            ...

Each package is only allowed to #include the top-level headers of another package, never ones in src/ directories.

Also, when you want to use Autotools in a large project and intend to distribute headers, it may prove to be prudent to call the top-level directory not src/ but by the PACKAGE_TARNAME of that project. This makes installing headers with the help of the Autotools easier.

(And, of course, the actual file names do not look as silly as illustrated above.)

回答3:

There's no reason not to divide your source code into different directories; it makes sense if there are many files and clear logical groupings.

It is not necessary to create a distinct file for each small class though - in large projects, that tends to slow compilation (as the implementation files often have to include a lot of the same headers just to compile their couple dozen lines).

As well as the use of namespaces for reflecting the logical divisions in the code, the exact thresholds at which code is subdivided into further namespaces tends to be driven by some other forces, for example:

• factors suggesting use of more namespaces
  • very volatile code (often edited, constant additional/changed identifier use, often short and/or common words)
  • more developers
• factors reducing the need for namespaces
  • tight coordination by a central body
  • planned formal releases with thorough checks for conflicts

Namespaces can also be used as a way to allow easy switching between alternative implementations (e.g. different versions of a protocol, thread-safe versus unsafe support functions, OS-specific implementations), so sometimes catering for such needs involves use of distinct namespaces.

It can definitely be painful digging through unintuitive and/or deeply nested namespaces to reach the variables you want, and "using namespace" is less effective if you're likely to need to use several that define the same identifiers anyway, but can suit more modal code that tends to use one or the other namespace more heavily at a time.

So, you may want to consider these factors when deciding whether to put each folder's code (or some other logically distinct group) into distinct namespaces.

回答4:

There's no reason not to and will really help people reading your code. Some things to watch out for:

1. Don't over-nest folders, this can be confusing for readers of your code.
2. Be consistent in the organization of your code, e.g. don't put any view code in the controllers sub-directory, or vice-versa.
3. Keep the layout clean.

回答5:

You can arrange your files however you like; you'll just need to adjust your build tools' include paths and source paths to match.

Giving each directory it's own namespace is overkill and probably a bad idea, as it will make for confusing code. I'd recommend one namespace per project at most, or even just one namespace per company (since presumably within your company you have the power to rename things if necessary to resolve name collisions. Namespaces' main purpose is to handle the case where two codebases under the control of two different organizations both use the same name, and you as a third party want to use them both in the same project, but don't have the ability to modify either codebase).

回答6:

The src/ is a common place there c/c++ programmers put their sources within the project root. For example:

doc/    <- documentation
libs/   <- additional libraries
po/     <- gettext translations
src/    <- sources

it common to create subdirectories underneath src/ if you've got a lot of sources files but there are no limitations how to organize this substructure.

Keep in mind that a directory structure in completely optional in c++. That is no connection between c++ namespaces and the directory structure.

来源：https://stackoverflow.com/questions/4240984/src-folder-structure-in-c