What's the preferred policy of header files in C++ projects: <test.h> or "test.h"?
In my experience I use:
#include <test_lib.h> to include C/C++ headers, third-part libraries (boost and etc.) which path specified in project settings.#include "my_test.h" - it's used for headers files existing in project.Any other practices can be applied here?
Is it ok to include header files with relative paths: like #include "../new_test.h"? Or is it better to move relative paths to project settings?
Angle brackets are use to include system headers. Theoretically, IIRC, they're not even necessarily files. In practice, <> means do not search current directory, only the include path, whereas "" means look in current directory and then search the include path.
As for relative paths, it probably depends on your environment, I'd suggest path relative to your project include path (as specified by -I).
This MSDN article explains how preprocessor searches for headers depending on the #include syntax form. Your style is good as Visual C++, Windows Framework, Boost and headers of other frameworks/packages are (usually) outside your project's directory.
Regarding your second question, my advice is to avoid relative paths. If you move around that header, you'll need to adjust that relative path by changing your code which is a bad idea. I'd rather put it within angle brackets and add path to it to /I option. E.g. you want to include C:\frameworks\frameworkA\include\a.h in your project, you can use #include <a.h> and \I "C:\frameworks\frameworkA\include"
It is maybe more descriptive if you add path to the framework root to /I and then put partial path to its header within angle brackets. E.g. #include <frameworkA\include\a.h> and /I "C:\frameworks". Now it's clear in the code that a.h belongs to frameworkA.
Use relative paths only for headers that are within your project's directory (e.g. if you organise code into modules which are in subdirectories of your project and which are not intended to be moved around).
You can use either. The <test.h> can be used by using the -I <directory containing test.h> option when compiling. In general, and this is a practice I follow, I tend to use <test.h> for all header files, irrespective of whether they are third-party header files or ones that I have written.
It might be a good idea to refrain from using relative paths "../test.h". From personal experience, this way of writing #include statements forces you to cement your directory structure. If you decided to move test.h tomorrow to a different directory, you would have to go into each one of the header files and change the relative path for test.h to the new path - a time consuming exercise. Better to shift this to the makefile (via -I) and then deal with it from there.
