Use of angle brackets around file names for include statements

[elfring]

Would you like to replace any double quotes by angle brackets around file names for include statements?

[nabijaczleweli]

For #include "filename" the preprocessor searches in the same directory as the file containing the directive.

Funny thing, this is exactly what's desired here!

[ThePhD]

@nabijaczleweli is right: in this case, we want the inclusion to be exact and direct. If that's troubling to you, you can use the single header that's on the v2.0.0 release page.

[elfring]

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?

[Nava2]

@elfring What do you mean by "duplicated file search?"

Most (all?) implementations use " as search the cwd first, then the system directories. This is exactly what is wanted in this context. When the library is installed onto a system, it would be installed either via the single hpp file or it is still local and in the proper search path. If the library is found via -I and <> then it would still search the cwd first then the system directories. This is the right, and expected behaviour.

Unless I'm completely missing something.

[elfring]

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"?

[sehe]

@elfring If you want to discuss a detail about how includes work and what - in general - would be best to use in what circumstances, please do so on a discussion forum, or perhaps a Q&A site like http://stackoverflow.com. Right now you're saying "there are different opinions" but "therefore: you must change your opinion".

I have a feeling it's not gonna fly and it's not important. I haven't seen a single rational argument why <> would be better in this case. I'm genuinely confused why this issue hasn't been closed yet.¹

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"?

If the file is not found, then the wrong include style has been used for the file. Like the GCC docs linked state:

• #include "file"
  

  This variant is used for header files of your own program.

There should not been "duplicate searching". Only if you use the wrong style /and/ the compiler implements the fallback search /and/ a name clash exists (which likely doesn't happen for #include "text/html/processing.hpp").

---

¹ apparently I missed it

[elfring]

If the file is not found, then the wrong include style has been used for the file.

Will "the angle brackets inclusion method" be usually triggered when you expect that the source file "sol/state.hpp" should be found in an installed system directory (instead of an other development folder)?

Only if you use the wrong style /and/ the compiler implements the fallback search

Do you know any compiler implementation which does not provide the specified "fallback"?

/and/

I find this interpretation interesting.

a name clash exists

Would you like to prevent this anyhow?

[sehe]

Will "the angle brackets inclusion method" be usually triggered when you expect that the source file "sol/state.hpp" should be found in an installed system directory (instead of an other development folder)?

@elfring this might be the essential point. I guess you could argue that public headers should use <> include style so it works best with usual -I, pkg-config, etc. approaches.

For internal includes, I'd say "" style is superior. It expresses intent. FWIW, I think the fallback is the only confusing factor here.

[elfring]

I guess you could argue that public headers should use <> include style so it works best with usual -I, pkg-config, etc. approaches.

I am trying to point this aspect out at various places.

[ThePhD]

This issue is ridiculous and you're clogging my e-mail.

If the inclusion style bugs you, download the header file from the release so you don't have to see the quoted includes.