Update CppCoreGuidelines.md

explicitly note that "file" refers to as it exists in the location of it being authored/modified.
this is to address any confusion about #including "bar.h" from foo.h based on whether bar.h is relative to foo.h at the time and location foo.h is being modified (e.g. under mylib/foo.h) versus at the time/location from which foo.h is installed to the system and included by the user (e.g. from /usr/include).
This commit is contained in:
apenn-msft
2020-07-23 14:41:33 -07:00
committed by GitHub
parent f4c80921d6
commit f458adae1f

View File

@@ -19189,7 +19189,8 @@ The [standard](http://eel.is/c++draft/cpp.include) provides flexibility for comp
the two forms of `#include` selected using the angle (`<>`) or quoted (`""`) syntax. Vendors take the two forms of `#include` selected using the angle (`<>`) or quoted (`""`) syntax. Vendors take
advantage of this and use different search algorithms and methods for specifying the include path. advantage of this and use different search algorithms and methods for specifying the include path.
Nevertheless, the guidance is to use the quoted form for including files that exist at a relative path to the file containing the `#include` statement and to use the angle bracket form everywhere else, where possible. This encourages being clear about the locality of the header relative to files that include it, or scenarios where the different search algorithm is required. It makes it easy to understand at a glance whether a header is being included from a local relative file versus a standard library header or a header from the alternate search path (e.g. a header from another library or a common set of includes). Nevertheless, the guidance is to use the quoted form for including files that exist at a relative path to the file containing the `#include` statement and to use the angle bracket form everywhere else, where possible. This encourages being clear about the locality of the file relative to files that include it, or scenarios where the different search algorithm is required. It makes it easy to understand at a glance whether a header is being included from a local relative file versus a standard library header or a header from the alternate search path (e.g. a header from another library or a common set of includes).
Note that this guidance applies to the including file as it exists in the location where it is typically authored/edited, and not any other location to which it may subsequently be copied or installed or otherwise made available to the implementation.
##### Example ##### Example