#pragma once is useful in Windows for the same reason they have the pre-compiled header abomination: slow directory-level file system operations and a really bad system header legacy. On the point that some headers should not use this mechanism: in addition to headers designed to instantiate something in-place, some headers include optional components activated by a user-specified define. The idempotent and flag-independent portions can be enclosed in a preprocessor include guard but the optional part should be left outside the guard. An example is the non-ANSI manifest constant set in <math.h> which Microsoft chose to enable by defining a symbol before including the header. By leaving that conditional block of definitions out of the include guard and *not* specifying pragma once for that file they ensured that #include <something.innocuous.that.includes.math.h> #define USE_MATH_DEFINES #include <math.h> works as expected. Another example: #define BOOST_TEST_MAIN #include "boost/test/unit_test.hpp" This causes a boilerplate "main" to be instantiated in your source file. If this were done outside the include guard then we could make unit_test.hpp (without main) part of the pre-compiled header and then re-include it in one compilation unit with the macro defined. #pragma once would make that impossible. By the way, the Microsoft include "optimization" story gets even goofier. They also have a magic cookie comment that you can include as the first line of a header that causes dependency analysis to ignore the file that contains the cookie and any subordinate dependencies. This was hacked into their C/C++ compiler to make incremental builds tolerable in the presence of the IDE-maintained headers defining resource IDs and such. Needless to say it causes all kinds of problems. One of which is that other consumers of those files do not honor the cookie in their dependency analysis. There is also a "minimal rebuild" mechanism mentioned in the compiler switch documentation that seems to have been intended to do a syntax-aware intra-compilation-unit dependency analysis. I have no idea what it really does but its existence is just one more clue as to how bad the performance of this compiler/file system/header suite combination is. -swn