Project files' tree

Question

Are there any articles or recommendations how to organize file hierarchy in your project? I am interested in how to name folders, to separate sources and headers or not.

I have project written in C++, a library and project using it. Library has many components, they are separated from each other but some of them use common files. Should I create directories for them?

I will be glad to hear all recommendations.

look at boost organization. it's pretty reasonable. – Gene Bushuyev Jan 06 '11 at 20:18 — Gene Bushuyev, Jan 06 '11 at 20:18
Duplicate of this? http://stackoverflow.com/q/1398445 – greyfade Jan 06 '11 at 20:19 — greyfade, Jan 06 '11 at 20:19

score 6 · Answer 1 · answered Jan 06 '11 at 20:06

6

Do not split headers and source files into separate folders. It does nothing more than add an extra folder level.

At best it is completely useless; if you're looking for "widget.h" you can trivially find it even if there's a "widget.cpp" right next to it. At worst it's rather counter-productive - e.g. when you're editing "widget.h" and find that you also need to update "widget.cpp".

answered Jan 06 '11 at 20:06

Roman Starkov

59,298
38
251
324

2

Yep. Especially since file lists are often sorted alphabetically, `widget.cpp` should be right next to its counterpart. – Maxpm Jan 06 '11 at 20:09
and what about component to separate folder? – Yevhen Jan 06 '11 at 20:10
2

Agree with you. If you separate headers from cpps most IDEs won't be able to jump from .h to .cpp and from .cpp to .h – Mircea Ispas Jan 06 '11 at 20:10
4

When you're making a library, as the OP says they are, you most definitely DO want to keep public headers separate from the main source tree. It makes deployment a whole lot easier. – Edward Strange Jan 06 '11 at 20:17
4

@Felics - don't know what silly IDE you're using but every single one that I have has had no problem with it. – Edward Strange Jan 06 '11 at 20:18
@Noah You can split them up when bundling the installer (or release archive or whatever you use) without forcing the library developers to actually write the code that way. – Roman Starkov Jan 06 '11 at 20:21
@Noah Roberts -- you definitely don't need to keep headers and sources in separate directories for that. Build systems typically extract only public headers and organize for release, which can be quite different from development configuration. – Gene Bushuyev Jan 06 '11 at 20:22
@Noah Roberts -- One of the IDE's you called "silly" is CodeGear C++ Builder, which is pretty advanced IDE I must say. And being able to use Ctrl-F6 to switch between header and cpp is quite convenient. Again, don't forget there are more than .h/.cpp files that create a unit, there maybe more, and they also may be automatically supported by IDE. – Gene Bushuyev Jan 06 '11 at 20:25
What do you all mean by "jump"? – John Dibling Jan 06 '11 at 22:35
@Felics - Actually, MSVS CAN jump. I use it every day. I have a src tree resembling most OS layouts with include/ and src/. They themselves are broken down into namespaces representing functionality areas. Just right click, say open. NBD. As to it not being necessary for sharing public headers only, sure..you can write a complex script that names every header, or you can use different extensions...but why when you can simply copy a directly en-masse to another location? It's very low maintenance that way. – Edward Strange Jan 07 '11 at 17:23

score 3 · Accepted Answer · edited May 23 '17 at 10:27

3

It's good to keep your namespaces in separate folders. Nest namespaces in the same manner as they are nested within your project. For instance, if you have:

namespace Foo{ namespace Bar{ } }

then you'd want any objects in the Bar namespace to be found in

{Foo's parent folder}\Foo\Bar\{how you're organizing code at this level}

We use an include folder for headers, a source for .cpp, a test folder for unit tests, and an object folder for compiled code bits. The reason we separate them is that it makes it easier to package the code in our scripts. You're always going to pass around the headers, you won't be passing around the source. (Here is another SO thread discussing separating header/source files. It's a preference thing.)

Here is a link to Google's style guidelines, if that helps.

edited May 23 '17 at 10:27

Community

1
1

answered Jan 06 '11 at 20:06

wheaties

35,646
15
94
131

1

what about headers in one folder and sources separated by some logic? – Yevhen Jan 06 '11 at 20:12
1

Just like others I don't like the idea of separating headers and cpp files in different folders. One thing is #include's (or compiler options) will need to specify paths. The other thing, one of IDEs I use, automatically create units of .h/.cpp files with #includes and guards, so it would be pain to separate them. – Gene Bushuyev Jan 06 '11 at 20:14
@TGadfly what better logic is there than a strict divide in folders? – wheaties Jan 06 '11 at 20:15
I meant all headers in one folder, and sources by separate folders. logic means i.e. network - one folder, input- another. I liked that google's guidelines) – Yevhen Jan 06 '11 at 20:19

score 2 · Answer 3 · answered Jan 06 '11 at 20:19

I don't separate headers from source : it's a pain to browse

I usually have the subdirectories match my namespaces

+ Project root
    + <project_name>   // namespace project
        - sub_dir_1    // namespace project::sub_dir_1
        - sub_dir_2    // namespace project::sub_dir_2

I only add "Project root" as an additional include path, so includes have the form :
```
#include "project/sub_dir_1/a.h"
#include "project/sub_dir_2/b.h"
```
Because source and header are usually named according to the class they contain, the whole qualified named can be deduced from the include path :

project::sub_dir_1::a is found in project/sub_dir_1/a.h
a.c trivially includes a.h (relative path provided)
If I must include a.h from b.h, I use absolute path (starting from the project/ root)

Project files' tree

3 Answers3