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?

[kghose]

@elfring is this causing problems because you are compiling Magnum directly with your code? Just asking because I use it as an installed library and it's not affected me and I'm curious about why.

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

[kghose]

Sorry, I'm a newbie, I still don't follow.

• Is this slowing down compile times?
• Are you compiling Magnum directly into your program i.e. you have the source code as a subdirectory in your code and have integrated the make files?
• Are you having name clashes because you have some file names with an identical path in your project?

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

[kghose]

@elfring ah, thank you for the clarification. So it's not a particular issue you've run into right now.

I'm not involved with the project, just a user, but my personal preference is how things have been done now, as a visual indicator of what I can expect to belong to the project itself (quotes) as opposed to system or installed libraries (angle brackets). This helps when I inspect the magnum code.

In my project I end up using angle brackets when I include magnum elements as that is an installed library.

[elfring]

Do you care (for example) why the boost class library is using angle brackets in include statements for corresponding header files?

[kghose]

I don't use boost. But I suspect that if I were going through the boost library to learn concepts (as I do with Magnum) I would appreciate this, since it gives me a good visual indication of what is within the code base and what is external.

[mosra]

Hi again, @elfring! I'm having the following convention for #include "" vs #include <>:

• if the include is project-local (so not from system directories, but rather from the project tree), I'm using #include "". Example of including a corresponding header for a *.cpp file, example of Corrade project-local include, example of Magnum project-local include, example of Magnum Plugins project-local include
• if the include is from the system (example), from an external dependency (example) or from a dependent project -- so for example Corrade includes in Magnum (example) or Magnum includes in Magnum Plugins (example), then I'm using #include <>.

This convention is followed very consistently across all Magnum-related projects and helps me see, for example, when debugging something, if I need to patch something in the current project (which is easier) or outside some other (which takes time). Basically what @kghose said above (thank you, @kghose!).

I don't buy the performance concern you have, including a system header that's not needed has much bigger impact than this and unless you want to prove that with a reproducible benchmark, I'll take this as just a speculation. OTOH, for example using #pragma once (which I'm not doing yet) next to include guards does have measurable speed difference. Also, I wouldn't take boost as an example, especially in relation to comple times. Really? ;)

I see that you opened 88 similar issues in almost 50 other repositories just this month and since unfortunately I have much pressing things to work on than having a discussion on these topics, I'll close this one as "wontfix". I hope you can understand that and acknowledge the very detailed reasoning behing the current state I posted above.

[elfring]

• @kghose: 🔮 How do you interpret the visual indication (as a software user) if you would notice that an include statement (in the installed header file) continues to use quotes for other files (hopefully from an installed software library)?
• @mosra: You are the maintainer of this software library (and others?). The evolving source files (together with headers) can be treated as “project-local” while they are stored in your own development repository. But I find that the situation is significantly changed after these files were published as an official production release. Include statements in the officially released files should use angle brackets then, shouldn't they?

[mosra]

Man, this discussion is over, really. I thought it was clear. I stated all the reasons above and I'm not going to pour over everything and change things if it won't result in significant performance or usability improvement.

I really don't want to be mean and block / lock / report you, so please let's act like adults and stop the conversation here.