Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 09:30:33


----- Original Message -----
From: "Ed Brey" <edbrey_at_[hidden]>

> To clarify, #ifdef 0 can trivially be changed to #if 0 to make that line
> well-formed; however, the apostrophe continues to present a problem.

The guideline specifies that to comment out /code/ you should use #if 0

The guidelines prize reliability over convenience. If it is simply too
incovenient for some people to use '//', they will, I'm sure, ignore this
particular guideline.

> On other matters, the guidelines document appears to no longer be in the
> yahoo groups files section. Should I be looking someplace new?

Yes:
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/boost/boost/more/Attic/coding
_guidelines.html

> In particular, I was interested to read the rationale for mangling the
> header guards with a initials and a date. It seems that such mangling
> provides incrementally little value since there exist many other
> non-mangled macros in the code, and may even lend a false sense of
> security.

This sounds like FUD to me. It seems to me that the more non-mangled names
there are, the better mangling protects you against collisions.

I have been coding in Jam recently, where tokens are strictly
whitespace-separated and foo::bar, foo->bar, foo.bar and <foo!bar>baz/mumble
are all legal identifiers. It really changes one's perspective on
uniqueness, scoping, and security. ;-)

> 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!

-Dave


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