Difference between revisions of "Talk:cpp/preprocessor/include"
From cppreference.com
< Talk:cpp | preprocessor
(Term "current source file") |
(mention core guidlines) |
||
(One intermediate revision by one user not shown) | |||
Line 8: | Line 8: | ||
Where does the compiler now look for that "foo.hh" header first? In the directory where the current .cc file is or in /usr/local/include/libname/ ? I'd suggest the example section should contain this case, too. --[[User:Roker|Roker]] ([[User talk:Roker|talk]]) 07:56, 13 April 2021 (PDT) | Where does the compiler now look for that "foo.hh" header first? In the directory where the current .cc file is or in /usr/local/include/libname/ ? I'd suggest the example section should contain this case, too. --[[User:Roker|Roker]] ([[User talk:Roker|talk]]) 07:56, 13 April 2021 (PDT) | ||
+ | |||
+ | :The "current source file" is the file that is being processed i.e. the most nested #include at that point and what __FILE__ would be. You seem to be more concerned with how that file is found and the page makes it quite clear that that is implementation defined and an example is therefore not possible. | ||
+ | |||
+ | :Your example is a good example of why putting directories in include directives is generally a bad idea unless the library is specifically designed to be used that way (e.g. boost) in which case the "foo.hh" should probably be <libname/foo.hh>. | ||
+ | |||
+ | :I have seen recommendations to always use angle brackets for the reason that, in practice, you can always specify the search directories and their order with an option, usually -I or /I however this means that you could have a problem in the unlikely event that you had a header of the same name as an internal system header. | ||
+ | |||
+ | :[[Special:Contributions/194.74.130.171|194.74.130.171]] 01:11, 14 April 2021 (PDT) | ||
+ | |||
+ | :: C++ Core Guidelines has some recommendations on this topic, too: [https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rs-incform SF.12: Prefer the quoted form of #include for files relative to the including file and the angle bracket form everywhere else] - perhaps we can reference it --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 12:09, 14 April 2021 (PDT) |
Latest revision as of 11:09, 14 April 2021
[edit] Term "current source file"
It is a bit unclear to me what "current source file" means when headers include other headers.
Example: A .cc file contains an #include <libname/header.hh> that refers to a header file installed at /usr/local/include/libname/header.hh and this header file contains a
#include "foo.hh"
Where does the compiler now look for that "foo.hh" header first? In the directory where the current .cc file is or in /usr/local/include/libname/ ? I'd suggest the example section should contain this case, too. --Roker (talk) 07:56, 13 April 2021 (PDT)
- The "current source file" is the file that is being processed i.e. the most nested #include at that point and what __FILE__ would be. You seem to be more concerned with how that file is found and the page makes it quite clear that that is implementation defined and an example is therefore not possible.
- Your example is a good example of why putting directories in include directives is generally a bad idea unless the library is specifically designed to be used that way (e.g. boost) in which case the "foo.hh" should probably be <libname/foo.hh>.
- I have seen recommendations to always use angle brackets for the reason that, in practice, you can always specify the search directories and their order with an option, usually -I or /I however this means that you could have a problem in the unlikely event that you had a header of the same name as an internal system header.
- 194.74.130.171 01:11, 14 April 2021 (PDT)
- C++ Core Guidelines has some recommendations on this topic, too: SF.12: Prefer the quoted form of #include for files relative to the including file and the angle bracket form everywhere else - perhaps we can reference it --Cubbi (talk) 12:09, 14 April 2021 (PDT)