On 3/19/07 3:53 PM, in article
12*************@news.supernews.com, "Andrey
Tarasevich" <an**************@hotmail.comwrote:
The Cool Giraffe wrote:
>...
My, my, my... I get the point and i'd like to thank you for the
answer. However, i can't stop wondering why such utility isn't
by default a part of the language. What can such monsterity
(in my, beginners eyes) be useful for? I'm sure there's a
point to that and it'd be easier to live if i knew.
...
How exactly do you think it could look if it were "a part of the language"? In
this case we use include guards built from preprocessor directives and
preprocessor is a part of the language already. How much more "part of the
language" do you imply it could've been made?
Quite a bit - at least enough to eliminate the current kludge (the one
cobbled together from a preprocessor macro and an #ifdef) that a C++
programmers often must resort to - given the lack of a more reasonable
facility in C++ to prevent a translation unit from including the same header
file more than once.
A built-in header guard would have to be concise, accurate and clear (in
other words, everything that the current macro include guard is not). A
simple preprocessor directive would probably do the trick:
#once
In fact, several C++ compilers (Metrowerks, Visual C++, gcc) offer a
"#pragma once" which has the same semantics envisioned for the #once
directive above. So adopting #once would formalize and standardize an
existing, proven solution. The #once directive would for that reason carry
little technical risk - yet make C++ sources more portable, and their
dependencies, easier to manage.
Note that fully automatic unconditional protection from repetitive inclusion
of
the same header file into the same translation unit (if that's what you meant)
is not an acceptable solution, since in some cases we might actually want to
perform such a repetitive inclusion.
The idea would be to add #once to those header files that should be included
once - and not add #once to any header file that should be included more
than once by a single translation unit. I imagine that most C++ programmers
will be able to remember this straightforward guideline.
One can also mention that it was once a popular alternative approach to
handling
include dependencies, where interface-level headers were not supposed to be
included into other headers at all, meaning that in your example instead of
including 'A.h' into 'B.h' and 'C.h' you'd have to remember to include it into
'main.cpp'
#include "A.h"
#include "B.h"
#include "C.h"
Theoretically, this approach might lead to a better translation performance.
It
doesn't appear to be a significant issue today, but it definitely was a much
bigger deal, say, a decade ago.
Since C++ templates have moved code into header files, the old maxim that
headers should not include other header files - is no longer a practical
goal.
Maybe that's a part of the answer to your
"why"
question: at that time it was assumed that it is better to flag the
multiple-inclusion problem than to quietly handle it automatically or to
support
(and thus encourage) it in any way by some "part of the language" feature.
If the compiler is able to ensure that a header file is included only once
for a translation unit, what is the benefit of forcing the programmer to
accomplish the same result - but have to do so by laboriously tinkering with
complex include dependencies in a trial-and-error search for an #include
order that works?
After all, compilers should make programmers' jobs easier, not the other way
around (now that a programmer's time typically costs much more than the
computer's). And header guards are a good example where C++ could do more
for the programmer. I would estimate that about 99% of C++ headers that I
have seen contain header guards of one sort or another. And to have so
widespread a need be met by embarrassing preprocessor hacks or compiler
specific pragmas - is no excuse for C++'s continued benign neglect of this
issue.
Greg
