I know, this is an old question that has been asked many times before. I agree with the common answer that #include <filename> should be used for system headers and #include "filename" should be used for project-local headers.
However, now I found this paper from the ISO/IEC C++ Tools Working Group, which states the following:
All headers within a project should be included using the
<>style inclusion and contain the project name as a directory prefix. And all headers means all headers public, private, or implementation detail, in executables or in libraries.
They also give an explanation:
The problem with the
""style inclusion is if the header is not found relative to the including file, most implementations will continue looking for it in the include search paths, the same as for<>. As a result, if the header is not present in the right place (for example, because it was mistakenly not listed as to be installed), chances are that a completely unrelated header with the same name will be found and included. Needless to say, debugging situations like these is unpleasant.
I don't understand this. Why does this problem not occur with the <> style?
Bonus question: What's the status of such a paper anyway? Can it be considered an official recommendation of the ISO/IEC C++ consortium, peer-reviewed and acknowledged by many experts? Or is it just a proposal by someone in order to trigger a discussion?
I finally understood. The author of the paper suggests to use only include paths that are specified with the -I flag to the compiler, but not to use any relative search paths. This makes sense if the relative include path is always given in the #include statement, and only one -I flag needs to be given for the root of the project.
Anyway, it is a highly interesting paper that quite changed my understanding of how to structure C++ components. I'd wish to see more like this from the committee.