#include so called 'Best practice'
Author
I feel this question belongs in For Beginners really. [smile]
As far as I can think there are two common ways to refer to your header files when including them into your source files...
1) You can state the relative logical directory, i.e:
#include "..\Header Files\Header.hpp"
2) You can set an addition include directory for the project and then include header irrespective of where they're kept:
// Additional directory is: \Header Files
#include "Header.hpp"
Option 1 seems more portable compiler-wise and option 2 seems more flexible as it's not tied down to the directory structure.
In the past my own projects have essentially been one big mucky folder containing both header and source files, or else I adopt whichever it is already being used on the project. So I've never really had to think about this before - and I'm tempted to say it more or less a null issue either way.
Never the less, since I'm starting a new, large-ish, project I'm curious whether one of these is at all preferable to the other? What do people think?
The directory structure is part of your code organization, period. It's not a matter of flexibility: You've decided that a particular header is in a particular directory and if you change that you'll need to change the references, just like renaming variables.
One moderating factor to that, though... keeping track of ..s is annoying and doesn't lend clarity. I'm in favor of putting the base source directory in the include path, so you can do "physics/cv/capsule.h" instead of "../../../physics/cv/capsule.h".
BTW, you're not actually putting all your header files in one directory, and your source files in another directory..right?
One moderating factor to that, though... keeping track of ..s is annoying and doesn't lend clarity. I'm in favor of putting the base source directory in the include path, so you can do "physics/cv/capsule.h" instead of "../../../physics/cv/capsule.h".
BTW, you're not actually putting all your header files in one directory, and your source files in another directory..right?
Author
Quote:Original post by Sneftel
The directory structure is part of your code organization, period. It's not a matter of flexibility: You've decided that a particular header is in a particular directory and if you change that you'll need to change the references, just like renaming variables.
Sounds like you're purporting option 1 :-P
Quote:BTW, you're not actually putting all your header files in one directory, and your source files in another directory..right?
Well, I was thinking something like:
Project\Graphics\Header
Project\Graphics\Source
Project\Audio\Header
Project\Audio\Source
etc
I do feel somewhat mystified about what a good directory structure would look like - I've always been rather lazy when it comes to tidying files away into folders. [rolleyes]
Quote:Original post by dmatter
Well, I was thinking something like:
Project\Graphics\Header
Project\Graphics\Source
Project\Audio\Header
Project\Audio\Source
etc
I do feel somewhat mystified about what a good directory structure would look like - I've always been rather lazy when it comes to tidying files away into folders. [rolleyes]
Here's what will happen:
#include <abc/Header/foo.hpp>
#include <abc/Header/bar.hpp>
#include <abc/Header/baz.hpp>
Why are you stating it's a header when it's obvious from #define and .hpp part?
To separate, the basic layout is usually like this:
/include /Audio /Video /Util/src /Audio /Video /DX /OGL// no util, header onlyYou then put '/include' into include path, and reference headers directly:
#include "Audio/foo.hpp"
#include "Video/video_if.hpp"
#include "Util/baz.hpp"
But this is a topic where YMMV, since it depends on many factors, starting with choice of build and version management system.
Quote:Original post by Sneftel
I'm in favor of putting the base source directory in the include path, so you can do "physics/cv/capsule.h" instead of "../../../physics/cv/capsule.h".
That's what I do as well.
Quote:Original post by Sneftel
BTW, you're not actually putting all your header files in one directory, and your source files in another directory..right?
I never got why people do that. I find it confusing. I like to keep a 'module' (i.e., a source and header file) together in a directory. I always sort project directory views by file type anyway, seperating the headers and sources in two lists.
Quote:Original post by dmatter
Project\Graphics\Header
Project\Graphics\Source
Why? You can simply sort your files by extension, if you want a filtered list of the .h files.
What makes (some) sense is to separate out the public headers into a different dir, when building a library (which I very much suggest... static libraries are the best form of project-wide modularity). That still doesn't require much directory munging, though, since the public header just needs to include some private libraries (with directory stuff), and the rest of the library doesn't know about the public header at all.
Quote:Original post by Mike nl
I never got why people do that. I find it confusing. I like to keep a 'module' (i.e., a source and header file) together in a directory. I always sort project directory views by file type anyway, seperating the headers and sources in two lists.
This becomes a problem if you try to deploy any kind of pre-built libraries, where you need to ship only headers.
With deeply nested layout, you have a lot of hassle taking out the headers only. If you use separate include directory, you have all of them in one place already.
Quote:Original post by Antheus
With deeply nested layout, you have a lot of hassle taking out the headers only.
I don't follow you... this is merely an issue of filtering header files by extension in a directory tree. Where is the hassle in that?
Quote:Original post by dmatter
// Additional directory is: \Header Files
#include "Header.hpp"
Bear in mind that on big projects this approach can slow down your compiles since everytime the compiler wants to find an included file it has lots of additional directories to scan rather than just a relative path off a few base directories.
Any single-man project is unlike to get that huge though.
On disk, I have all my own files in one folder. Anything that I did not write is in a subfolder along with a copy of whatever licence it comes with and whatever else is necessary.
Then, in my IDE, I create filters for each group of files. The result is that I can find where everything is using the IDE, and I can see clearly which things are mine and which are not when I look at the directory structure.
This works well because then, in my #include directives, i either just use #include "ClassFoo.h" for my own stuff, or #include "SOIL/Soil.h" for the image library I am using. My current one man project, which is 6 months old, has 135 files that I wrote, plus another 100 or so that are part of libraries.
so, my folder is like:
+Source
|+SOIL
|+Bullet
|+SDL
|-ClassFoo.h
|-ClassFoo.cpp
+Build
I do not see the benefit of this method, but I am currenlty porting to VC9 so I am open to any suggestions.
Then, in my IDE, I create filters for each group of files. The result is that I can find where everything is using the IDE, and I can see clearly which things are mine and which are not when I look at the directory structure.
This works well because then, in my #include directives, i either just use #include "ClassFoo.h" for my own stuff, or #include "SOIL/Soil.h" for the image library I am using. My current one man project, which is 6 months old, has 135 files that I wrote, plus another 100 or so that are part of libraries.
so, my folder is like:
+Source
|+SOIL
|+Bullet
|+SDL
|-ClassFoo.h
|-ClassFoo.cpp
+Build
Quote:
/include
/Audio
/Video
/Util
/src
/Audio
/Video
/DX
/OGL
I do not see the benefit of this method, but I am currenlty porting to VC9 so I am open to any suggestions.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement