Recommend #pragma once for self-iteration
#51
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Compilers implement the "multiple-include optimization" for included files when they can detect that subsequent includes will have no effect. With Clang, GCC, and Microsoft Visual Studio this will occur when encountering a `#pragma once`, or when there is a **top-level** include guard. The idiom of self-inclusion with Boost Preprocessor requires that the include guard is nested within the `#if !BOOST_PP_IS_ITERATING` and therefore does not meet the strict criteria for the previously mentioned build optimization. The documentation has been updated to suggest `#pragma once` after all self-includes have occurred. This will allow the compiler to avoid any subsequent includes for the current translation unit and avoid extra work for the preprocessor.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Compilers implement the "multiple-include optimization" for included files when they can detect that subsequent includes will have no effect. With Clang, GCC, and Microsoft Visual Studio this will occur when encountering a
#pragma once, or when there is a top-level include guard.The idiom of self-inclusion with Boost Preprocessor requires that the include guard is nested within the
#if !BOOST_PP_IS_ITERATINGand therefore does not meet the strict criteria for the previously mentioned build optimization.The documentation has been updated to suggest
#pragma onceafter all self-includes have occurred. This will allow the compiler to avoid any subsequent includes for the current translation unit and avoid extra work for the preprocessor.