Re: [boost] Suggested coding guidelines

From: Ed Brey (edbrey_at_[hidden])
Date: 2001-07-03 11:28:57

From: "David Abrahams" <david.abrahams_at_[hidden]>
>
> > 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.
>
[...]
>
> >  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.

The other reason I think this topic generates such interest is that a
design pattern that mangles some macros, but not all, is engaging in
probabilistic engineering, which is unreassuring.  One longs for a
solution that guarantees success.

Now that I've had a chance to look over the document, I have a few other
comments.

First, it is very good overall - quite well laid out.

The rationale for not using /* */ to comment out code mentions that the
syntax highlighter won't pick up a problem due to lack of comment
nesting.  My experience is that the syntax highlighter does this just
fine.  When you insert the closing */, iff the code above it isn't
comment-colored, you have a problem.

2.14, "Names containing double underscores", seems overbearing.  Why not
forbid a prefixed single underscore only when it will result in
undefined behavior?

6.6, "Use const whereever possible": The wording is too strong.  While a
good idea in general, for small functions, it is sometimes more trouble
than it worth.  For example, the example at the end of section 4 should
be "int f(int const x) {return x+1;}" given this rule as written.

8.2 "Make all data members private": What is the rationale for the
strength of "Protected data members are forbidden." versus saying simply
to avoid protected data members?

8.4 "Function definitions in the class body are forbidden". It is my
understanding that a function that soes nothing but expose a constant
version of a member variable is quite reasonable to declare within the
class definition.  Any reason why this usage is not mentioned here?