Re: [boost] Suggested coding guidelines

From: Jeff Paquette (paquette_at_[hidden])
Date: 2001-07-03 11:39:06

----- Original Message -----
From: "Ed Brey" <edbrey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 03, 2001 12:28 PM
Subject: Re: [boost] Suggested coding guidelines

[snip]
> > >  A consistent style of BOOST_XXX seems to be adequate, so long
> > > as the include guards match the file path so to avoid conflicts
> within
> > > boost.  If the end user is worried about a conflict, he need only
> grep
> > > his code for BOOST_, and needs to do so with or without include
> guard
> > > mangling.
> >
> > Yeah, that would probably be enough, but it requires more care to get
> right
> > than initials and a date. What is the problem with this guideline? It
> works
> > sufficiently well, and is sufficiently easy to follow. I don't
> understand
> > why it generates so much interest!
>
> For me the interested was generated from a natural longing for
> consistency.  The theory goes, if mangling is a good thing, it's a good
> thing, so why not BOOST_DECL_MGL121200?  The answer of course is that
> most macros are referenced in potentially many places, whereas macro
> guards are only referenced in a handful of places, so mangling is
> practical for header guards.  The longing for consistency raises the
> real issue is that, even though there is little harm in mangling, is
> there even less benefit, such that it's not worth it.  Header macros are
> just one link in a the macro chain, and yes, strengthing it does provide
> benefit; however, it seems too small to be worth even minor
> inconvenience.
[snip]

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

--jdp