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?

[warrenseine]

Unfortunately, no. I think we're doing it the correct way (quotes for internal headers, brackets for system headers). If you need to include a specific header, simply add framework/include to your include path.

Please describe your issue if this is a problem for you.

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

[JMLX42]

What are the actual consequences of using " " instead of < > ?

[elfring]

Would you like to clarify implementation details for C++ preprocessors any more than the information I referred to before?

[warrenseine]

So far, there hasn't been any problem with the current include approach. Moreover, LLVM, Chromium, Firefox and pretty much all projects use the double-quote approach. We're only changing code when it's actually fixing things. Is our include path breaking code on your side?

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

[JMLX42]

There must be something like 1 000 000 lines of code when you compile the whole SDK. Taking all the different platforms (Windows, OS X, Linux, Android, iOS, HTML5...), architectures (32bits, 64bits), release and debug builds, it adds up to (dozens ?) of gigabytes of compiled/linked binaries.

I am "pretty sure" the eventual "search" for each included header has little to no impact on the compiling performances. Especially considering we have only a few include dirs so that this linear search must have a constant negligeable time impact.

In other words, this "issue" is orders of magnitude smaller than anything useful and mandatory the build process implies. "fixing" this will not improve anything in measurable any way. Still, if you measure any signficant performance difference using angle brackets, please let us know.

[elfring]

Do you reuse the parameter "iquote" for the tool "g++" already?

[warrenseine]

No, we didn't. But, instead of referring to the documentation, please tell us what your actual issue is. So far, I had never heard of -iquote, though I use GCC quite often. I haven't had any issue yet that needed this option, and apparently, I'm not the only one. Again, what you're suggesting might be helpful, only if it solves an issue.

[elfring]

I try to clarify and improve the fine-tuning for header file search directories. I'm "curious" if other software developers care also for the affected implementation details.

[JMLX42]

I think that the implementation details have little to no impact here considering the amount of code at hands here. On Sep 10, 2014 10:15 AM, "Markus Elfring" notifications@github.com wrote:

I try to clarify and improve the fine-tuning for header file search directories. I'm "curious" if other software developers care also for the affected implementation details.

— Reply to this email directly or view it on GitHub https://github.com/aerys/minko/issues/178#issuecomment-55084209.