3 ms·
> I guess this has been solved by include guards/pragma once a long time ago include guards don't really solve this problem, because the preprocess needs to re
by coliveira 6y ago
> I guess this has been solved by include guards/pragma once a long time ago
include guards don't really solve this problem, because the preprocess needs to read every line to find the end of the include guard. The pragma once solution works, but it is hard to implement it for every system (what happens when a file has different names but same content)?
- john_moscow 6y ago>The pragma once solution works, but it is hard to implement it for every system (what happens when a file has different names but same content)? I would say, that qualifies as "good enough". The amount of headache saved from accidentally having 2 guards with the same name it way more than the requirement to NOT have multiple symbolic paths to the same file used at the same time. That said, modern compilers just use inode number (and a similar thing on Windows), that covers about 99.9% of real-world systems where you want to build.
- spatulon 6y agoMicrosoft's compiler has an optimization that means it doesn't even open the header file a second time if the include guard surrounded all non-comment tokens. I imagine gcc and clang do something similar. Of course, they also recommend using "#pragma once" unless you're really concerned about portability. Source: https://docs.microsoft.com/en-us/cpp/preprocessor/once?view=vs-2019 https://docs.microsoft.com/en-us/cpp/preprocessor/once?view=... > The compiler recognizes the include guard idiom, and implements the multiple-include optimization the same way as the #pragma once directive if no non-comment code or preprocessor directive comes before or after the standard form of the idiom:
- coliveira 6y agoThis is all nice, but not portable. C++ has no formal concept of a "builder", every new invocation of the compiler is independent, so it doesn't know how a previous invocation parsed a particular header file.