From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-07-03 15:59:03
----- Original Message -----
From: "Ed Brey" <edbrey_at_[hidden]>
> Yes, if in the final tally, the number of error with mangling is
> approximately equal to number of errors without mangling, then the
> mangling isn't worth it. (Note that this does not preclude mangling
> being useful for other reasons, such as reducing maintenenace during
You measure the probability of all colliding macros, but you could just as
easily measure the probability of all colliding names (in which case
namespaces are a waste of time, because the probability of colliding macros
overwhelms them?) or of all coding errors (in which case almost any
guideline is a waste of time, because most code has errors in it) or of just
colliding #include guards (which justifies my guideline). If an error is
easily avoidable, it's worth avoiding, IMO.
> > I don't want to have that argument. It seems entirely too pedantic.
> Iroincally, the point of the argument is that the mangling itself is
> pedantic, since it involves effort and rules with little tangible
I guess I don't agree with the way you measure benefit. IMO, we are not
going to convince one another, so, with respect, I withdraw from this
> > It also is easier than remembering exactly which contexts you're
> allowed to
> > use names starting with underscores. A simple rule, if not overly
> > restrictive, is more powerful than a complicated one.
> True. But it is also easier to read (for me) _member than m_member in
> code, and there is a tradeoff. I think the documents selection of
> forbidding the leading underscore and calling for m_ is fine, but as
> with any tradeoff, it is very valuable to include the thinking behind
> it, so it is easier to determine when, if ever, a different choice
> becomes in order.
OK, I will add more rationale.
> True. About all you can say is what you mentioned in your warning in
> the first paragraph.
> > They're common English words; you can check the dictionary. The coding
> > standard means what it says.
> That "forbid" is a common English word is exactly why I raised the
> point. To me "forbid" means "never", which left be confused for a while
> as I was reading the guidelines until I pieced together a deduction of
> the authors' intent. I don't connote any sense of exceptionalism with
> the word. As such, the out-of-the-box meaning of forbid doesn't fit
> well with the guidelines intent, which is "don't do this without a
> demonstratable need".
Once again, the guideline really means what it says. However, I can't
control whether people follow the guideline.
> > If you want to write a preamble that describes "forbidden" and "avoid"
> > everything else, by all means, do so. I doubt it would strengthen the
> > document; in fact I think it would weaken it. Maybe others will feel
> > differently.
> Maybe a better approach is to use a word that conveys the intent
> out-of-the-box. Personally, I think "abstain" would do the job. So
> depending on how uncommon are situations where the rule should be
> broken, the guidelines can say to abstain from x or avoid y.
"Forbidden" conveys the intended meaning, but I could change it to "abstain"
for the purposes of boost (where nobody, at least so far, intends to mandate
compliance). If the group feels a change of this nature would be a good one,
I'd like to take suggestions for alternative words also.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk