Boost logo

Boost :

From: Corwin Joy (cjoy_at_[hidden])
Date: 2001-06-23 00:21:53


----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Friday, June 22, 2001 8:33 PM
Subject: Re: [boost] Question about leading underscores

> At 08:09 PM 6/22/2001, Corwin Joy wrote:
>
> >The trouble with putting two underscores in a variable name is that you
> >might end up colliding with a preprocessor
>
> The discussion was about single underscores never followed by an uppercase
> letter, never at namespace scope. IOW, totally standard conforming.
>

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].

So let's take a paranoid example where things could go wrong:

// your library might define
#define wchar_t _long_char
// The above is allowed by 17.4.3.1.4 which says that types from the
Standard C library can live at the global namespace level (are reserved to
the implementation), wchar_t is such a type.

so if you have a class e.g.
foo {
private:
    int _long_char;
    wchar_t _wide_char;
...
}
you may be in for a surprise. Really the above only happens if your
compiler defines a macro for a type or function - so hopefully you will be
safe, OTOH, consider how the old (deprecated) version of <ctype.h> worked on
many compilers:

extern unsigned short *_pctype;
#define isspace(_c) ( _pctype[_c] & _SPACE )
#define ispunct(_c) ( _pctype[_c] & _PUNCT )
#define isalnum(_c) ( _pctype[_c] & (_UPPER|_LOWER|_DIGIT) )
#define isprint(_c) ( _pctype[_c] &
(_BLANK|_PUNCT|_UPPER|_LOWER|_DIGIT) )
#define isgraph(_c) ( _pctype[_c] & (_PUNCT|_UPPER|_LOWER|_DIGIT) )

again, a problem if you have a member variable called _pctype.


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