|
Boost : |
From: Alberto Barbati (abarbati_at_[hidden])
Date: 2002-12-30 05:18:41
Gennaro Prota wrote:
> Hmm... frankly I haven't used it anymore. I'm under the impression
> they have fixed it now, but last time I checked it had a lot of bugs.
> It was easy, for instance, to end up including the same file twice if
> it was reached through different paths (e.g.: #include "subdir/file.h"
> in A.cpp and #include "file.h" in subdir/file2.h). Usually one doesn't
> notice the error, because he uses both the pragma and the canonical
> include guard, but that means of course that the speed gain comes to
> nothing. Probably it was VC++ 5.0 though.
You are missing the point here. "#pragma once" is not really
"functional", in the sense that it's not (or should not be) used
*alone* to realize the "include me once" effect. That effect is better
achieved by the canonical include guards that should be used anyway (and
*will* be used anyway in portable code).
"#pragma once" is just an optimization issue. If a file is included a
second time in the same TU, a dumb compiler will re-open it and give it
to the preprocessor who strips its contents entirely because the include
guard is already defined. Re-opening + preprocessing takes little but
significant time.
With the "#pragma once" the programmer just gives an hint to the
compiler that re-opening is unnecessary and ignores the #include
directive immediately. You see, there *is* a speed gain even in the
presence of canonical include guards.
Of course, a smarter compiler like g++ will recognize the canonical
include guards and deduce that re-opening is unnecessary without any
explicit hint given by the programmer.
> [...] In effect, the whole story about file inclusion should be
> the other way round: any source file is included at most once for each
> TU, unless the programmer requires otherwise ;-)
I agree, but we can't give the burden of avoiding multiple inclusions to
the "user". Realistically, with large projects such intent is hardly
achievable by anyone.
Alberto
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk