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?

[patrikhuber]

Hi Markus, we're using the following "convention":

• Double quotes for local includes, e.g. from eos itself, and for the immediate dependencies pulled in by the submodules
• Angle brackets for system includes (standard library).

There's a few cases sort-of in-between these two, like OpenCV or Eigen, you could make a case to use either angle brackets or double quotes. In the end, the choice is not really important, it's more important to be consistent, which we are.

Your right in that we technically don't require the compiler to look for include files in the current directory of each file (as described in the SO post you linked), because eos/include is added to the compiler's include paths and that's also what every user should do. However in practice double quotes work just as fine in that case too, and I see an advantage in the visual message that we convey ("This is a local include, not from the system"). Unless you've got a good argument for using angle brackets everywhere, I am not (yet?) convinced.

[elfring]

Your right in that we technically don't require the compiler to look for include files in the current directory of each file …

Thanks that you can think in such a software design direction.

---

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?

[patrikhuber]

That's an interesting point. Does the "duplicated file search" really happen? I guess this depends on the compiler but I am wondering whether in practice any compiler does not add the directories given by -I to the search directories for double-quote includes. They could certainly do that since the standard allows "implementation-defined" and I would actually guess that most compilers do that. gcc seems to, in the link you posted it says "and then the same directories used for ".

What do you mean with " restrict the searched directories for header files of your software"? The link you linked didn't help me understand what you could've meant. Could you maybe make an example?

From my perspective, the "visual message" that we can convey with double quotes and angle brackets is still the argument, because I have yet to see or hear of any case where this strategy fails in practice or has a disadvantage in practice. I know of many open source projects that also use this or a very similar strategy, and it all seems to work very nicely. Of course that doesn't mean that there's no better way, so I'm very open to improvements, if there is a practical improvement, and one that outweighs the benefits of the current convention. Have you encountered any practical examples where the current strategy used by us and many open source project fails or is suboptimal?

[elfring]

I guess this depends on the compiler …

I suggest to take another look at the situation for an application programmer (and software build parameters which could be preferred here). The required header files will be installed in a known directory.

• Do you expect then that the desired header files are usually not found in the source directory which is used by the programmer?
• Should headers be directly retrieved from a trusted include directory (without a lookup attempt from an other storage location)?

I prefer to avoid possible misunderstandings around the wording “the same directory”.

[patrikhuber]

From an application programmer's perspective, I expect them to have this library installed somewhere - either in their system, local package manager, or just in their home directory. In all of these cases I expect them to then either use CMake, which handles include paths (and works perfectly fine with the current strategy of double quotes / angle brackets), or to specify the eos include directory manually, which is /the/users/local/directory/eos/include, and then everything works fine too from a user's as well as compiler's perspective.

I don't think we're getting anywhere here. Actually, upon further inspection of your GitHub profile, I found that you posted the exact same issue in dozens of other GitHub repositories over the last couple of days, and you very often reply with the same, apparently pre-written comment messages. I'm really not sure what your goal here is, but I am closing this for now, until there's some substantial reason to re-open it, for example a use case where using double quotes fails for a user or where it is shown that a compiler's compile time is significantly longer.

Thanks nonetheless for bringing this up and for the various interesting links.

[elfring]

…, I found that you posted the exact same issue in dozens of other GitHub repositories over the last couple of days, and you very often reply with the same, apparently pre-written comment messages.

This is my approach to adjust the situation for hundreds (or even thousands?) of published software components somehow.

My goal is for this issue to clarify specific software build parameters and their influence on the preferred application structures.

:crystal_ball: Would you like to distinguish the contribution of code for libraries and programs any further?

---

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