Re: Include guards and inclusion order
On Dec 3, 12:43 am, Juha Nieminen <nos...@thanks.invalid> wrote:
Pete Becker wrote:
On 2007-12-01 21:38:27 -0500, Juha Nieminen <nos...@thanks.invalid> said=
:
Include guards are more or less mandatory so you shouldn't drop those=
..
(I don't really understand why the C++ standard can't simply state that=
if a file is included more than once, only the first inclusion is taken=
into account; I can't think of any use for multiple inclusion of the
same file in such way that its contents is parsed for each inclusion,
bar some really ugly obfuscated preprocessor trickery which nobody
really needs anyways.)
Read about <assert.h>.
I did, and I still can't understand why including <assert.h> several
times would make a difference.
Never the less, it's very frequent. Anytime the profiler says
that your assertions are a performance problem. You don't want
to turn them off everywhere, nor even in every function in the
file where the performance problem occurs. Normally, you'd wrap
the offending function in something like:
#ifdef PRODUCTION
#define NDEBUG
#include <cassert>
#endif
// critical function...
#undef NDEBUG
#include <cassert>
The assert macro was carefully designed especially to support
this idiom. It's the way it was meant to be used; you're not
really supposed to defined NDEBUG globally, ever.
So while it is certainly "really ugly obfuscated preprocessor
trickery", anybody who's concerned with performance needs it.
And anyways, even if it did make a difference, wouldn't it be better
to simply have some kind of #pragma or whatever which tells the compiler
"it's ok to include this file more than once", the default behavior
being, when that #pragma does not appear, that multiple inclusions are
ignored?
Not really. Or at least, that's not enough. What is really
needed is two directives: #include and (say) #import. The first
would work exactly like it does today. The second would compile
the file in an isolated context, and then import whatever it
defined. So that things like "#define string char const*", for
example, would not cause problems if you did "#import <string>".
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34