0

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?

Georg P.
  • 2,785
  • 2
  • 27
  • 53
  • 3
    "*Can it be considered an official recommendation of the ISO/IEC C++ consortium, peer-reviewed and acknowledged by many experts?*" No. Until it becomes an actual ISO standard or Technical Specification, it's just a proposal. – Nicol Bolas Aug 28 '19 at 20:32
  • 5
    As far as I understand, it says *`""` is bad, because it does precisely the same thing as `<>`*. Also, this paper is basically just a bunch of opinions - "I like this convention, why is not everyone using it"? – Yksisarvinen Aug 28 '19 at 20:38
  • I recommend refraining from placing path names into the source file. If the header files move, then the source needs changing. Prefer to supply the path names to the compiler. – Thomas Matthews Aug 28 '19 at 21:36
  • I prefer placing path names into the source files. If the header is moved, the compiler will notify the user. For me, any search that finds 'the missing header' has a chance to also find any other header files of the same name. On a large system I worked on, there were 5 copies of doo.hpp (3 different versions), providing a 80% chance I modified the wrong one on my first try, despite being in the 'dominant' version. I prefer 'relative path's. – 2785528 Aug 28 '19 at 23:42
  • I would like `#include >header.hpp<` which would exclude searching the standard locations if not found in the project specific locations :-) – Ted Lyngmo Aug 29 '19 at 18:53

1 Answers1

0

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.

Georg P.
  • 2,785
  • 2
  • 27
  • 53