Use of angle brackets around file names for include statements about bond HOT 8 CLOSED

#include with double quotes are used intentionally when we are including a file from the same directory or a path relative to it. This is the case for the example you linked.

If you find a case where there is an double-quote #include and file is included from the include path, please do send a pull request.

from bond.

I assumed that the referenced header file belongs to your public application programming interface, doesn't it?

from bond.

Yes. When you include it in your program you should include it as following (that's what the examples do):

#include <bond/core/apply.h>

But when we include it from another header in bond/core we use #include "apply.h". In part that is a convention but this is also the most unambiguous way to include it: #include <bond/core/apply.h> could be "hijacked" by the user of Bond, either by accident or on purpose, by putting another file with that name in front of include path.

from bond.

It seems that I do not really understand the purpose for your kind of distinction around such API header usage so far.

from bond.

The distinction is not based on whether header is API or not but where it should be included from: the same directory or include path.

What advantage do you see in looking for such headers in the include path first? Either preprocessor will find the file in the same directory (which is what #include with quotes will always do) or it will find another file, in which case it will be wrong.

from bond.

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 bond.

I'm going to close the issue as won't fix and I think we are over-analyzing it. Both conventions are plausible and different libraries use them. But since you are quoting the standard I want to point out that the standard actually has even more hardcore recommendation against using the < > form than the convention we adopted. The standard recommends that the < > form should be used only for header files provided by the implementation (i.e. the standard library), see the note 7 in section 16.2 Source file inclusion of C++11 standard:

[Note: Although an implementation may provide a mechanism for making arbitrary source files 
available to the < > search, in general programmers should use the < > form for headers provided 
with the implementa-tion, and the " " form for sources outside the control of the implementation. 
For instance:
#include <stdio.h>
#include <unistd.h>
#include "usefullib.h"
#include "myprog.h"
—end note]

from bond.

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 bond.