Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-10-26 11:45:30


Redundant include guards are seldom worth the trouble.

1. In most cases #include guards are an undocumented implementation detail
and subject to change.

2. The above is true for ALL boost libraries.

3. Several compilers include an optimization which detects #include guards
and skips re-reading the header.

===================================================
  David Abrahams, C++ library designer for hire
 resume: http://users.rcn.com/abrahams/resume.html

        C++ Booster (http://www.boost.org)
          email: david.abrahams_at_[hidden]
===================================================

----- Original Message -----
From: "Wismar, John" <john.wismar_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Friday, October 26, 2001 12:35 PM
Subject: RE: [boost] RE: [Boost-Users] array -v- array_traits

> > -----Original Message-----
> > From: David Abrahams [mailto:david.abrahams_at_[hidden]]
> > Sent: Friday, October 26, 2001 7:55 AM
> > To: boost_at_[hidden]
> > Subject: Re: [boost] RE: [Boost-Users] array -v- array_traits
> >
> >
> > This demonstrates why using a little bit of name mangling in
> > #include guards is a good idea. I use my initials and the
> > date, which surely would have prevented this problem if
> > either author had done it.
>
> On the other hand, that makes it very inconvenient to use redundant
include
> guards. (See "Large Scale C++ Software Design" by John Lakos, section
2.5.)
>
> If the include guards are generated from the filename, then the file
system
> itself can be used to guarantee the uniqueness of the macro.
>
> -------------------------------
> John Wismar
> Architect, Software Development
> AllData, a division of AutoZone
> mailto:jwismar_at_[hidden]
>
>
> Info: http://www.boost.org Unsubscribe:
<mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk