 |
C++Talk.NET C++ language newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ted Guest
|
Posted: Wed Feb 08, 2006 2:00 pm Post subject: Multiple include guards in header files |
|
|
The stand libary that is a part of my compiler (BC++) has the typical
include guards in the header files, but it also wraps the #include of
the header in files that use it:
// _defs.h
//
#if !defined(___DEFS_H)
#define ___DEFS_H
// header stuff here
#endif /* ___DEFS_H */
// stdarg.h
//
#if !defined(___DEFS_H)
#include <_defs.h>
#endif
Is the guard in stdarg.h just to speed up compiles? It sure looks ugly
and is a lot of typing to adopt such technique.
Ted
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Trevor Morgan Guest
|
Posted: Wed Feb 08, 2006 3:00 pm Post subject: Re: Multiple include guards in header files |
|
|
Yes, the idea is that it speeds up compilation times. The point of
include guards is that the code in the header file only gets parsed
once for each compilation unit, but the preprocessor will still open
and inspect the file each time it encounters a #include.
With these extra 'external' include guards, each header file will only
be opened once.
This page contains a discussion as to whether it's actually worth it.:
http://www.gamearchitect.net/Articles/ExperimentsWithIncludes.html
Some compilers, such as Microsoft VCC, use a '#pragma once' mechanism
to achieve the same effect, with less typing.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Guest
|
Posted: Wed Feb 08, 2006 5:00 pm Post subject: Re: Multiple include guards in header files |
|
|
Ted wrote:
| Quote: | The stand libary that is a part of my compiler (BC++) has the typical
include guards in the header files, but it also wraps the #include of
the header in files that use it:
// _defs.h
//
#if !defined(___DEFS_H)
#define ___DEFS_H
// header stuff here
#endif /* ___DEFS_H */
// stdarg.h
//
#if !defined(___DEFS_H)
#include <_defs.h
#endif
Is the guard in stdarg.h just to speed up compiles? It sure looks ugly
and is a lot of typing to adopt such technique.
|
Yes, it's there just for speed. However, keep in mind that stdarg is a
file that's
typed only once, but compiled very very often. Furthermore, it's part
of the
implementation, which is why it can and must use such ugly names.
__DEFS_H is definitely not something that a good user would define.
HTH,
Michiel Salters
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
Ivan Vecerina Guest
|
Posted: Wed Feb 08, 2006 5:00 pm Post subject: Re: Multiple include guards in header files |
|
|
"Ted" <rt (AT) local (DOT) net> wrote in message
news:sD9Gf.18818$_S7.10797 (AT) newssvr14 (DOT) news.prodigy.com...
: The stand libary that is a part of my compiler (BC++) has the typical
: include guards in the header files, but it also wraps the #include of
: the header in files that use it:
:
: // _defs.h
: //
: #if !defined(___DEFS_H)
: #define ___DEFS_H
:
: // header stuff here
:
: #endif /* ___DEFS_H */
:
: // stdarg.h
: //
: #if !defined(___DEFS_H)
: #include <_defs.h>
: #endif
:
: Is the guard in stdarg.h just to speed up compiles? It sure looks ugly
: and is a lot of typing to adopt such technique.
Yes, this trick may help speed-up compiles on some platforms.
GCC, I believe, has an automated identification of include guards,
making the redundant check pointless (it is able to automatically
skip reading the included file's contents).
--
http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ] |
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|