Most C++ compilers now support the non-standard #pragma once compiler directive.  This directive instructs the compiler to #include the file only once in a single compiland, and replaces the old C-style header sentinels (often called #include guards).

The central problem with preprocessor based header sentinels is that they require the user to create a unique symbol to identify each and every header file that might be #included by a single compiland.   On very large projects, this burden becomes somewhat painful.  Consider also the distinct possibility that two libraries might contain public header files with the exact same name; using the typical __FILENAME_H__ convention, its very possible to run into name collision between the two libraries.   Some project teams attempt to avoid this problem by imposing a strict sentinel naming standard, usually including a file's path as part its sentinel name.  I'm not fond of this solution because if a header file needs to be moved, as occurs when refactoring a library, it requires that the header file be edited to conform to its new location.  The #pragma once directive avoids all this nonsense entirely.

A secondary problem is one of efficiency.  The #pragma once directive allows the compiler to avoid opening and preprocessing a header file after its been seen once.  Although it is technically possible for a compiler to implement a similar mechanism when it encounters the header sentinel pattern (GCC can do this for instance), the mechanism is a bit fragile because it depends on a user following an exact coding pattern for the optimization to work correctly.  I’ve encountered code patterns in library header files that appear to be the header-sentinel pattern, but are in fact not.  Moreover, the compiler must account for the fact that preprocessor symbols can be explicitly #undef’d.  I much prefer the explicit directive because it states exactly the intention of the programmer -- "include this header only once".

Unfortunately for users of GCC, this compiler directive has been deprecated (although it’s still supported last time I checked).  It’s my personal opinion that this is yet another case of Gnu’s pervasive NIH syndrome (they got it bad), however the official reason is that the construct is not portable (which I admit is technically true).  I do not understand why the standards committee hasn’t adopted it into the ISO standard.  It’s a trivial compiler feature to implement.  Although its not an official language feature, most C/C++ compilers support it.