#include "graphic/sprite.h"
#include "../some_other_dir/foo.h"
[C++] Put some code files in subdirs?
Author
The list of files in my project is getting quite big and it is hard find the file I'm looking for. I guess I could put some files in a subdirectories but how do I do this in the best way?
I think I should group files that belongs together into the same directory like graphic/, serialization/ and so on but how will I include it from other files later?
Say I want to include the sprite class in a file from parent directory, I could write:
My concern with this is that if I want to use some other file that's in another directory I get a lot of ugly things like ".." in the path.
Also if I move one file to another directory I will have to change the include for all files that uses it.
I think I have seen other projects that uses directories but just includes the file name. Is this to recommend? And how is it accomplished?
Quote:My concern with this is that if I want to use some other file that's in another directory I get a lot of ugly things like ".." in the path.You shouldn't have to use "..".
*** Source Snippet Removed ***
There's two types of include directives in C/C++.
#include "path/relative/to/current/file"
#include <path/relative/to/project>
e.g. say you've got the following directory structure:
/project/project/graphics/project/physics#include "spriteHelpers.h" // opens /project/graphics/spriteHelpers.h#include <physics/boundingBox.h> // opens /project/physics/boundingBox.hQuote:Also if I move one file to another directory I will have to change the include for all files that uses it.This isn't really a problem in my experience. e.g. How often do you move a graphics file into the physics directory, etc?
Author
Sounds good Hodgman but if I use <> it does not find the file to include.
I have always used <> for std:: files, and "" for my own files. Is it a good idea to mix or should I always use <> to be consistent?
I have always used <> for std:: files, and "" for my own files. Is it a good idea to mix or should I always use <> to be consistent?
You could add your main project source directory as an include search path, so when you do include <physics/boundingBox.h>, it will look in your main directory, find the directory physics and then find the file you were looking for.
Hodgman has this one incorrect. "" searches for local files, and <> searches for local or system include files. There is no way to specify "relative to project root", because C++ does not have the concept of a "project".
What I generally do is add my project root source directory to the system includes, so all my paths can be relative to this root and I don't need to use directory climbing.
What I generally do is add my project root source directory to the system includes, so all my paths can be relative to this root and I don't need to use directory climbing.
Quote:Original post by rip-off
Hodgman has this one incorrect. "" searches for local files, and <> searches for local or system include files.
Hmm?
Quote:From the C++ Standard, Section 16.2, paragraphs 2 and 3
A preprocessing directive of the form# include <h-char-sequence> new-line
search a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is search for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read# include <h-char-sequence> new-line
with the identical contained sequence (including the > characters, if any) from the original directive.
Fair enough, my mistake.
In my defense, I originally wrote it as you described. I was unsure, because I hadn't used C++ in a while. I briefly tested it in MSVC and it appeared to work as I described, so I assumed that that was the standard behvaiour. Odd.
In my defense, I originally wrote it as you described. I was unsure, because I hadn't used C++ in a while. I briefly tested it in MSVC and it appeared to work as I described, so I assumed that that was the standard behvaiour. Odd.
Quote:Original post by WoohYep, that happens with both file-relative and root-relative paths unfortunately.
Also if I move one file to another directory I will have to change the include for all files that uses it.
What I do is set the project's root folder as an include search path, then files include like so:
#include "project/subsystem/somefolder/file.hpp"
I try to keep the directory structure pretty broad and shallow, you don't want to be in a position where the structure is so deep and specific that slight shifts in a file's responsibility suddenly cause it to hop from folder to folder. Unless you have decent refactoring tools this kind of thing is just another headache that you don't want to deal with; if you don't deal with it though it'll just lead to code rot.
I prefer to use folders to structure things logically as opposed to merely separating things for the sake of reducing the number of files in a folder so that I can find them faster. In the latter case I find Visual Studio's filters pretty useful. If for whatever reason you don't want any paths in your #includes then you could just have all the files in the project's root and just structure things with filters so you can find them as easily as with real folders.
Author
Thank you all for your help. I got it working now.
Quote:Original post by SiCraneSo there is no need to use <>? I can use "" always for my own files, nice :)Quote:From the C++ Standard, Section 16.2, paragraphs 2 and 3
A preprocessing directive of the form# include <h-char-sequence> new-line
search a sequence of implementation-defined places for a header identified uniquely by the specified sequence between the < and > delimiters, and causes the replacement of that directive by the entire contents of the header. How the places are specified or the header identified is implementation-defined.
A preprocessing directive of the form# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the source file identified by the specified sequence between the " delimiters. The named source file is search for in an implementation-defined manner. If this search is not supported, or if the search fails, the directive is reprocessed as if it read# include <h-char-sequence> new-line
with the identical contained sequence (including the > characters, if any) from the original directive.
Quote:Original post by dmatter
Yep, that happens with both file-relative and root-relative paths unfortunately.
I've worked on projects where all project subfolders were recursively added to the search path. We had a fairly extensive directory structure, but we just used <> and filenames for our includes. Thus we could use directories to organize the files in our project, but our #includes would still act as if we had our entire project in a single directory.
Obviously, that comes with the limitation of requiring unique names for source files even if they are in different directories. There may have also been other limitations that I did not encounter (and if you know of any, I'd love a warning). But nevertheless it was nice to have the code entirely decoupled from the directory structure.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
