Closed. This question is opinion-based . It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post .
Closed 6 years ago.
This post was edited and submitted for review 46 mins ago.
Improve this question
While orienting myself to one of the open source C++ project I found a line of code in the root CMakeLists.txt file:
include_directories(${PROJECT_SOURCE_DIR}/../include)And then in one of the source files there is this line:
#include "someFolder/someFile.h"someFolder is found in include folder.
I have seen a different approach in another project, in which the CMakeLists.txt has something like this:
include_directories(${PROJECT_SOURCE_DIR}/../include/someFolder)then in the source file:
#include "someFile.h"The first approach typically "namespaces" the include path by the name of the project the header belongs to. Are there common benefits to this when integrating multiple projects together? If so, what are those common benefits?
2条答案
按热度按时间czq61nw11#
I prefer subdirectories for include files.
The main reason for this is to avoid file name conflicts. If dependency
Ahas a file calledsomeFile.h, and dependencyBalso has a file calledsomeFile.h, you got a problem, because the compiler doesn't know which one to include.So for the same reason you should use namespaces, you should also use subdirectories for include files when possible.
bmp9r5qi2#
Well, this is very opinion based, in my opinion...
I prefer the former approach, especially for larger libraries. It exhibits the logical structure of the library as intended for by the authors.