Re: [boost] Re: Question about leading underscores

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-06-24 14:56:43

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Sunday, June 24, 2001 2:03 PM
Subject: Re: [boost] Re: Question about leading underscores

> At 01:52 PM 6/24/2001, Corwin Joy wrote:
>
>  >IMHO leading underscores in member names seem to me
>  >to be not worth the anxiety of wondering if you are going to
>  >collide with something non-standard in one of the libraries
>  >you include.  I can understand why folks like underscores
>  >to seperate out module variable names, but it seems to me
>  >like a trailing underscore gives the same effect but in a safer
>  >way from a defensive coding point of view.
>
> I'm beginning to agree with you about a leading underscore.  But why don't
> you feel the same way about a trailing underscore?
>
Well, two reasons.
1. It is my *opinion* that a lot of the library writers have
taken the standard's allowance for them to put names leading with _[a-z]
into the global namespace as a license to create macros with these names as
well.  So, these are the kinds of names  that are most subject to
a collision.

2. As a less subjective metric, I went ahead and greped the Microsoft VC 6.0
include files
for two regular expressions:
'[a-z]_[ (]' = rough guess at trailing underscore matches - comes back with
about
50 matches, all public ones of the form _*_ so both a trailing and a leading
underscore
were present.

'_[a-z]' = 63738 matches - slightly cheating becuase picks up double
underscore
'__[a-z]' = 7134 matches - double underscore matches
gives roughly 56,000 matches for single leading underscore followed by
lowercase letter.

Admittedly, most of these matches will not be unique, but the short story
seems to be
that you are *much* more likely to have a collision with a leading
underscore
than a trailing one. (Provided that you don't have both a trailing and
leading underscore).

> In fact if we are trying to avoid problems caused by non-standard headers,
> particularly those which include macros, it is hard to know what is safe,
> beyond doing something really ugly.
>

Trust no-one.... macros may be lurking even in your own home...  :-)
I agree, once you move beyond the standard you can't say much about what
will happen,
but I think one can take a look at existing practice and try to avoid common
pitfalls.

Corwin