In the CeeLanguage
you can guard against the contents of a header file being parsed more than once by using an IncludeGuard
// The whole rest of the file goes here
#endif // The last line in the file
If the preprocessor sees this file a second time it will ignore everything between the #ifndef and the #endif - i.e.
the whole body of the file.
Are you bothered by the file being read every time it's included? Then try RedundantIncludeGuards
It seems IncludeGuard
s is enough. I think of RedundantIncludeGuards
as an implementation detail that hurts maintainability and should be something dealt with by the compiler.
... and then there's the RealWorld
Most tests on modern compilers (such as KAI or MSVC) show the difference in compilation time between normal IncludeGuard
s and RedundantIncludeGuards
to be any where from non-existent to milliseconds. Are RedundantIncludeGuards
worth the time saved? Not for me, but do your own experiments and decide which is more important to you - a OnceAndOnlyOnce IncludeGuard
or the slightly faster compile times of RedundantIncludeGuards
? Also don't forget there are multiple ways to skin a cat - using PrecompiledHeader?
s or creating smaller lexical units, for example, are preferable to RedundantIncludeGuards
is not necessarily wide-spread (remember, the RealWorld
). Also, what size had the "most tests" systems. Pre-compiled headers introduce problems of their own, at least if they are implemented like in MSVC.
RedundantIncludeGuards may be useless, but IncludeGuards are important to prevent classes, typedefs, macros, etc. from being declared multiple times, which can result in compile failure.
Am I the only person that wonders if recurring includes is a symptom of a system structure that needs fixing? (see LargeScaleCppSoftwareDesign
) -- SvenDowideit
Actually, while I don't agree, I think it was Lakos in LargeScaleCppSoftwareDesign
that recommended the use of RedundantIncludeGuards
CategoryCee CategoryCpp CeeIdioms