Skip to content

Conversation

@IncludeGuardian
Copy link

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.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant