Re: Pragma Once & Headers
On 4/19/07 12:18 AM, in article 3ECVh.248803$6P2.email@example.com, "James
Dennett" <firstname.lastname@example.org> wrote:
Will #pragma once or some similar facility be available in the next
My guess is "almost certainly not".
The prospects are dim - I agree.
If not, what's the reasoning behind standardizing it?
Among the reasons:
(1) A more robust solution exists within the current language;
....if only someone knew where to find it.
In fact there is no evidence that C++ even acknowledges the problem of how
to prevent multiple inclusions of a single header file in one translation
unit. After all, if C++ had a robust solution for this problem, then there
would have been no need for so many C++ compilers to have implemented a
"#pragma once" on their own, nor would C++ programmers have to resort to
preprocessor hacks like "header guards" (a non-standardized convention that
is anything but robust) - as a homemade replacement for an absent language
(2) I don't know of any rigorous proposal ever having been made
to the committee to add "#pragma once";
(3) If such functionality were added, it should not (IMO) be as
I agree. For standardization the "#pragma once" directive would become a
"#once" preprocessor directive.
(4) Defining what "the same file" means in a useful sense has
proven illusive, particularly when network file systems are
taken into account. This appears to lead to a situation
where conventional include guards would be necessary in any
case if writing portable code, in which case there is no
benefit to #pragma once except when working with a poor
quality compiler/preprocessor. The good implementations
avoid opening a file twice if it's suitably protected by
the normal #ifndef/#define/#endif guards;
The preprocessor in order to support a #once directive would not care
whether two header files are the "same file" or not (any more than it would
care whether the two headers correspond to actual "files" in the first
place). Instead, the preprocessor would simply have to decide whether the
contents of one header file (before preprocessing) is identical to the
contents of a header file brought in by an earlier #include directive (and
in which the preprocessor found a #once directive). If the contents are the
same, the #include directive is skipped and not processed.
Note how the simplicity, elegance and effectiveness of a #once directive
only makes the shoddiness and inadequacy of current workarounds (such as
they are) all the more embarrassing. "Header guards" are just such an
example. One particularly striking observation about header guards is - that
for all the tedious manual labor involved in placing them in headers - as a
solution to the one problem they are meant to address - they turn out to be
very robust at all. Because - although a header guard does prevent its
header file from being included a second time - it does not prevent another
header file with identical contents from being included nor does it prevent
a header file that has not yet been included from being excluded anyway by
mistake (because a header guard is neither unique nor does it uniquely
identify the header file in which it appears).
(5) Many programmers find it quite straightforward to program
their editors to generate suitable include guards, or to
configure their SCM system to do so;
So if the lack of a #once directive is not a problem for those C++
programmers, it must not be a problem for any C++ programmer anywhere else?
And why is it that certain kinds of software (apparently editors and source
code control systems in particular) have no difficulty in preventing a
header file from being included twice - while other kinds of other software
(such as a C++ preprocessor in particular) are simply not capable of
duplicating this feat?
(6) Other areas of C++ are more in need of improvement;
(7) When writing non-portable code, #pragma once is already
quite widely available in implementation-defined forms.
Code that relies on a "widely available" language feature is portable -
that's what "portable" means. In fact, being widely available suggests that
a broad demand for a #pragma once-like facility exists (despite reason #5)
- and should leave any questions as to its feasibility to rest (despite
I guess a better question would be, why are headers not automatically
included only once? Isn't this the desired behavior 99% of the time?
The issue seems to come down to: what does it mean for two
#includes to refer to "the same" header. Simple identity of
names isn't enough, and identity of contents isn't really
No, the question is quite simple: What does a programmer who adds a #once
directive to a header file expect that directive to do? Once that question
is answered, everything else just falls into place - it's not any more
complicated than that.
Clearly, the purpose of a #once directive is to prevent the subsequent
inclusion of the current header's contents. Otherwise the compiler would
interpret the header's declarations when processing them the second time as
another set of declarations that conflict with the first. So it must also be
the case that a #once directive would have to exclude any header file with
identical contents - because the consequences of including the other header
file would be indistinguishable from a header including itself. So as far as
the preprocessor and the #once directive are concerned any two header files
with identical contetns are the same - while any two that differ are not. In
that way the #once will work exactly as the programmer expects.
Now it's important to note that a #once directive addresses the most common
problem when managing include files - but it does not solve every problem.
In particular, a programmer will still have to avoid name collisions or
violations of the One Definition Rule (such as declaring the same entity in
more than one header file) - neither a #once directive nor a header guard
can help with those problems.
C++ would greatly benefit from a module system instead of
crutches for #include, and some on the committee are working
towards such a thing, but it's a large job and won't be in
Which is all the more reason why an interim improvement to C++ antiquated
model of textual file inclusion - a feature that carries minimal risk and
has a long history among diverse implementations - would make a lot of sense
as an addition to C++.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]