Pragma once

In the C and C++ programming languages, codice_1 is a non-standard but widely supported preprocessor directive designed to cause the current source file to be included only once in a single compilation. Thus, codice_2 serves the same purpose as include guards, but with several advantages, including: less code, avoidance of name clashes, and sometimes improvement in compilation speed. On the other hand, codice_2 is not necessarily available in all compilers and its implementation is tricky and might not always be reliable.
Example.
struct foo 
 int member;
In this example, the inclusion of codice_4 in both codice_5 and codice_6 would ordinarily cause a compilation error, because a struct with a given name can only be defined a single time in a given compilation. The codice_2 directive serves to avoid this by ignoring subsequent inclusions of codice_4.
Advantages.
Using codice_2 allows the C preprocessor to include a header file when it is needed and to ignore an codice_10 directive otherwise. This has the effect of altering the behavior of the C preprocessor itself, and allows programmers to express file dependencies in a simple fashion, obviating the need for manual management.
The most common alternative to codice_2 is to use codice_12 to set an #include guard macro, the name of which is picked by the programmer to be unique to that file. For example,
... contents of grandparent.h
This approach minimally ensures that the contents of the include file are not seen more than once. This is more verbose, requires greater manual intervention, and is prone to programmer error as there are no mechanisms available to the compiler for prevention of accidental use of the same macro name in more than one file, which would result in only one of the files being included. Such errors are unlikely to remain undetected but can complicate the interpretation of a compiler error report. Since the pre-processor itself is responsible for handling codice_2, the programmer cannot make errors which cause name clashes.
In the absence of #include guards around codice_10 directives, the use of codice_2 will improve compilation speed for some compilers since it is a higher-level mechanism; the compiler itself can compare filenames or inodes without having to invoke the C preprocessor to scan the header for codice_16 and codice_17. Yet, since include guards appear very often and the overhead of opening files is significant, it is common for compilers to optimize the handling of include guards, making them as fast as codice_2.
Caveats.
Identifying the same file on a file system is not a trivial task. Symbolic links and especially hard links may cause the same file to be found under different names in different directories. Compilers may use a heuristic that compares file size, modification time and content. Additionally, codice_2 can do the wrong thing if the same file is intentionally copied into several parts of a project, e.g. when preparing the build. Whereas include guards would still protect from double definitions, codice_2 may or may not treat them as the same file in a compiler-dependent way. These difficulties, together with difficulties related to defining what constitutes the same file in the presence of hard links, networked file systems, etc. has so far prevented the standardization of codice_2.
The use of #include guard macros allows dependent code to recognize and respond to slight differences in semantics or interfaces of competing alternatives. For example,
... use one known API
... use another known API
In this case, the direct determination for which API is available would make use of the fact that the include file had advertised itself with its #include guard macro.
The codice_10 directive is defined to represent a programmer's intention to actually include the text of a file at the point of the directive. This may occur several times within a single compilation unit, and is useful for evaluating macro-containing contents multiple times against changing definitions of the macro.
The use of codice_2, like the use of #include guard macros within an include file places the responsibility upon its authors in order to protect against undesired multiple inclusion. Over-reliance upon either mechanism on the part of programmers by direct, unprotected use of codice_10 directives without their own #include guard will lead to failure when using an include file that has not protected itself with either mechanism.