Boost logo

Boost :

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-06-24 12:52:32


----- Original Message -----
From: <rwgk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, June 24, 2001 10:42 AM
Subject: [boost] Re: Question about leading underscores

> --- In boost_at_y..., "Corwin Joy" <cjoy_at_h...> wrote:
> > Fair enough. But I claim you are still not technically safe if you
> prefix
> > with an underscore, because, as specified in the standard
> 17.4.3.1.2, "Each
> > name that begins with an underscore is reserved to the
> implementation for
> > use as a name in the global namespace". [note that this says
> nothing about
> > whether the underscore is followed by an uppercase letter].
>
> I am the original poster who started this thread. My question
> was motivated by a problem with the following piece of code:
>
> struct IspaceData {
> std::map<Miller::Index, int, Miller::hashCompare> IndexDict;
> sgtbx::SgOps _sgops;
>
> IspaceData(sgtbx::SgOps& s):_sgops(s){}
> };
>
> With the Compaq Tru64 version 6.2 cxx compiler, this eventually
> results in unresolved symbols. If "_sgops" is replaced by something
> that does not start with an underscore, compiling and linking
> succeeds.
>
> In view of the messages in this thread, and in view of our
> own experience, wouldn't it be better to strictly avoid the use
> of leading underscores in the boost library? It is a very low
> price to pay, compared to the trouble one has to go through
> if some unfortunate compiler's use of identifiers conflicts
> with that of the library.
>
> Thanks!
> Ralf

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.

Corwin


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