Re: [boost] Suggested coding guidelines

From: Ken shaw (ken_at_[hidden])
Date: 2001-07-03 12:30:41

----- Original Message -----
From: "Jeff Paquette" <paquette_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 03, 2001 12:14 PM
Subject: Re: [boost] Suggested coding guidelines

> ----- Original Message -----
> From: "David Abrahams" <david.abrahams_at_[hidden]>
> To: <boost_at_[hidden]>
> Sent: Tuesday, July 03, 2001 12:50 PM
> Subject: Re: [boost] Suggested coding guidelines
>
>
> >
> > ----- Original Message -----
> > From: "Jeff Paquette" <paquette_at_[hidden]>
> >
> > > Include guards can and are also used to prevent the header from being
> > > reparsed (as suggested by Lakos). As such, it (IMHO) would be better
if
> > the
> > > guard referenced the file name.
> > >
> > > I'd rather write:
> > >
> > > #if !defined(BOOST_XXX)
> > > #include "boost/xxx"
> > > #endif
> > >
> > > than
> > >
> > > #if !defined("68C2D2A0-6FD1-11d5-8F0C-00105AC8B6E1")
> > > #include "boost/xxx"
> > > #endif
> >
> > This practice is unreliable with most headers. For example, you can't do
> > that with your system headers if you're writing portable code. Most
> standard
> > and 3rd party libraries don't document their #include guard conventions,
> so
> > you have to look inside the header to determine what guard they used --
> and
> > there's no guarantee they won't change it.
>
> The argument is not about standard headers, is it? How many of us do that?
>
> > We could of course establish such a convention with boost headers, but I
> am
> > unconvinced of the benefits.
> >
> > Finally, many modern compilers have learned to recognize #include guards
> > such that this functionality is automated and you get zero benefit from
> > cluttering files with such checks.
>
> Interesting! Could you cite some examples? MSVC's "#pragma once" doesn't
> count.
>

gcc does this and also supports #pragma once. see the preprocessor docs for
the details.

Ken Shaw