Use of angle brackets around file names for include statements about memory HOT 7 CLOSED

I have the convention that #include "..." stands for a file inside the library and #include <...> for a file outside the library.

Do you have any problem or counterargument to this convention?

from memory.

I suggest to reconsider the consequences of the following wording from the section "16.2 Source file inclusion" in the standard specification for the programming language "C++".

…
The named source file is searched 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
…

• How do you think about to avoid "a duplicated file search" here?
• Would you like to restrict the searched directories for header files of your software?

from memory.

Yes, I know the differences between "" and <> for header files.
But in the example you've pointed to, I've included a file in the current directory, so I've written "#include "detail/utility.hpp", which is exactly the purpose of "".
If I have used <>, it would not work since it is not on the search path, I've needed to write #include <memory/detail/utility.hpp> or #include <foonathan/memory/detail/utility.hpp> since the search path is depended upon a CMake option.

Please provide an example how the way I've used "" creates a real problem.

from memory.

There are different opinions about the handling of the involved implementation-defined behaviour.

• Will header files be also searched outside the specified include directories if double quotes are used for the discussed preprocessor statement?
• Is there a speed difference measurable if a file is not found there and the search will be retried with "the angle brackets inclusion method"?

from memory.

Let me elaborate my situation a little bit. I have the following directory structure:

include/
  foonathan/
    memory/
      allocator_traits.hpp
      tracking.hpp

The file tracking.hpp includes the file allocator_traits.hpp via "".
On all compilers I know the implementation-defined behavior means look in directory of tracking.hpp, so it will look and find allocator_traits.hpp and include it. There is no need to retry the search with angle brackets.

If I've used <>, it would have looked in the search path. Depending on a CMake option, this is either include/foonathan/ or only include/. It will not find the header in the search path, unless I change either the search path or the whole include statement.

As for the case where there is also a file allocator_traits.hpp in the client code, this will not be included by the statement in tracking.hpp so this is not a problem either.

from memory.

That is indeed the same convention I and many others use. It does not shock
me, for what it's worth.
For such low level header files, in a large project where compilation
performance is a very real issue, these sort of headers typically end up in
pre-processed header files where their cost is largely reduced to begin
with.

On Sun, Sep 13, 2015 at 6:44 AM, Jonathan Müller [email protected]
wrote:

Let me elaborate my situation a little bit. I have the following directory
structure:

include/
foonathan/
memory/
allocator_traits.hpp
tracking.hpp

The file tracking.hpp includes the file allocator_traits.hpp via "".
On all compilers I know the implementation-defined behavior means look
in directory of tracking.hpp, so it will look and find
allocator_traits.hpp and include it. There is no need to retry the search
with angle brackets.

If I've used <>, it would have looked in the search path. Depending on a
CMake option, this is either include/foonathan/ or only include/. It will
not find the header in the search path, unless I change either the search
path or the whole include statement.

As for the case where there is also a file allocator_traits.hpp in the
client code, this will not be included by the statement in tracking.hpp
so this is not a problem either.

—
Reply to this email directly or view it on GitHub
#1 (comment).

from memory.

And since there is no overhead because the angle bracket search is not necessary and will fail, I am closing the issue now. If there is any more discussion, I will consider it again.

from memory.