«

I've heard that some compilers reserve the '_' starting a symbol for system
variables/symbols. I can not find this documented anywhere (so far). I've
used an '_' at the end of member variables (ie. Uint16 bar_; ) to
distinquish private fields, but this does not stand out as much as if the
'_' were at the begginning of the name as in the following class
declaration.

class Foo {
private:
Uint16 _baz;
Uint32 _bar;

public:
....
};

BRIAN VICKERY wrote:

> I've heard that some compilers reserve the '_' starting a symbol for
> system variables/symbols.

The C++ language reserves some of them, like e.g. those that begin with
an underscore followed by an uppercase letter and those that contain
two consecutive underscores.

> I can not find this documented anywhere (so far).
> I've used an '_' at the end of member variables (ie. Uint16 bar_; )
> to distinquish private fields,

That's quite common practise.

> but this does not stand out as much as if the '_' were at the
> begginning of the name as in the following class
> declaration.
>
> class Foo {
> private:
> Uint16 _baz;
> Uint32 _bar;
>
> public:
> ....
> };

I think those shold be fine.

"BRIAN VICKERY" <> wrote in message
news:LKuSb.110$...
> I've heard that some compilers reserve the '_' starting a symbol for
system
> variables/symbols. I can not find this documented anywhere (so far).
I've
> used an '_' at the end of member variables (ie. Uint16 bar_; ) to
> distinquish private fields, but this does not stand out as much as if the
> '_' were at the begginning of the name as in the following class
> declaration.
>
> class Foo {
> private:
> Uint16 _baz;
> Uint32 _bar;
>
> public:
> ....
> };


From 17.4.3.1.2 of the Standard:



Certain sets of names and function signatures are always reserved to the
implementation:

- Each name that contains a double underscore (_ _) or begins with an
underscore followed by an uppercase letter (2.11) is reserved to the
implementation for any use.

- Each name that begins with an underscore is reserved to the implementation
for use as a name in the global namespace.

BRIAN VICKERY wrote in news:LKuSb.110$:

> I've heard that some compilers reserve the '_' starting a symbol for
> system variables/symbols. I can not find this documented anywhere (so
> far). I've used an '_' at the end of member variables (ie. Uint16
> bar_; ) to distinquish private fields, but this does not stand out as
> much as if the '_' were at the begginning of the name as in the
> following class declaration.
>
> class Foo {
> private:
> Uint16 _baz;
> Uint32 _bar;
>
> public:
> ....
> };
>

Am identifier with single leading undersore is reserved for the
implementation if:

Its followed by an uppercase letter (anywhere).

Its followed by another underscore (anywhere), in fact *all* identifiers
that *contain* 2 or more *consecutive* underscores are reserved.

Its declared at global namespace scope, i.e its a macro or it
*isn't* declared within an namespace, class, struct or union or it
*isn't* a paramiter name or a local variable name.

Also IIUC it shouldn't be a declared extern "C".

So you usage for member identifiers is Ok.

Nobody really likes it though and most people can't be bothered to
remember all the rules, so they will probably complain that your using a
reserved identifier anyway, so I'd suggest m_baz or some such thing.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

"Rob Williscroft" <> wrote in message:

>
> Am identifier with single leading undersore is reserved for the
> implementation if:
>
> Its followed by an uppercase letter (anywhere).
>
> Its followed by another underscore (anywhere), in fact *all*
identifiers
> that *contain* 2 or more *consecutive* underscores are reserved.
>
> Its declared at global namespace scope, i.e its a macro or it
> *isn't* declared within an namespace, class, struct or union or it
> *isn't* a paramiter name or a local variable name.
>
> Also IIUC it shouldn't be a declared extern "C".
>
> So you usage for member identifiers is Ok.
>
> Nobody really likes it though and most people can't be bothered to
> remember all the rules, so they will probably complain that your
using a
> reserved identifier anyway, so I'd suggest m_baz or some such thing.
>

I'm familiar with the language from the standard, but it sounds a bit
ambiguous:

"reserved to the implementation for use as a name in the global
namespace"

could mean:

(i) reserved to the implementation; also, must be global,

or

(ii) reserved to the implementation if used in the global namespace

Why do you prefer (i)? Is this known to be the correct interpretation?

Jonathan

"Jonathan Turkanis" <> wrote in message
news:bved3v$q8s8r$...
>

> Why do you prefer (i)? Is this known to be the correct
interpretation?

I meant (ii) here.

Jonathan

On Fri, 30 Jan 2004 16:29:49 +0100, Rolf Magnus <>
wrote:

>BRIAN VICKERY wrote:
>
>> I've heard that some compilers reserve the '_' starting a symbol for
>> system variables/symbols.

Check 17.4.3.1.2 of the C++ standard first.

Stroustrup says "never" ... (see p. 81 of the 3rd edition, "The C++
Programming Language).


--
Bob Hairgrove

Jonathan Turkanis wrote in news:bved3v$q8s8r$-
berlin.de:

>> So you usage for member identifiers is Ok.
>>
>> Nobody really likes it though and most people can't be bothered to
>> remember all the rules, so they will probably complain that your
> using a
>> reserved identifier anyway, so I'd suggest m_baz or some such thing.
>>
>
> I'm familiar with the language from the standard, but it sounds a bit
> ambiguous:
>
> "reserved to the implementation for use as a name in the global
> namespace"
>
> could mean:
>
> (i) reserved to the implementation; also, must be global,
>

This would be the same as reserved ... everywhere. The "must be global"
would be unnessasery additional info'.

> or
>
> (ii) reserved to the implementation if used in the global namespace
>

[from elswhere]

> I meant (ii) here.

> Why do you prefer (i)? Is this known to be the correct interpretation?
>

Sorry but (i) doesn't make any sense to me.

_lowecase identifiers are used to support the C standard library and
meny C++ implementation's just use the C library as-is, and most
allow you to link with C code that will link in the C library.

C++ needs another set of identifiers _Uppercase so it doesn't stomp
on the _lowecase ones and also the double underscore rule for name
mangaling. This allows a C++ compiler to compile via a C compiler
as meny still do.

Rob.
--
http://www.victim-prime.dsl.pipex.com/

Rob Williscroft <> wrote in message news:<Xns9480A10CB54DukcoREMOVEfreenetrtw@195.129. 110.201>...
> BRIAN VICKERY wrote in news:LKuSb.110$:
>
> > I've heard that some compilers reserve the '_' starting a symbol for
> > system variables/symbols. I can not find this documented anywhere (so
> > far). I've used an '_' at the end of member variables (ie. Uint16
> > bar_; ) to distinquish private fields, but this does not stand out as
> > much as if the '_' were at the begginning of the name as in the
> > following class declaration.
> >
> > class Foo {
> > private:
> > Uint16 _baz;
> > Uint32 _bar;
> >
> > public:
> > ....
> > };
> >
>
> Am identifier with single leading undersore is reserved for the
> implementation if:
>
> Its followed by an uppercase letter (anywhere).

From memory, Microsoft C++ used to (not sure now), define a special
keyword called "_except". If you tried to use that name, even as a
member variable of a class, the compiler would spit the dummy.

Thus, regardless of what the standard for C++ says, don't necessarily
expect Microsoft to adhere to it.

Graham Dumpleton wrote in news:dc6f5c99.0401301624.544b4b2
@posting.google.com:

>
> From memory, Microsoft C++ used to (not sure now), define a special
> keyword called "_except". If you tried to use that name, even as a
> member variable of a class, the compiler would spit the dummy.
>

yes also things like _far, _near, _try all of which are extemsion
keywords

> Thus, regardless of what the standard for C++ says, don't necessarily
> expect Microsoft to adhere to it.
>

Well did MS introduce the keyword before or after the standard
came out (199. Certainly I've noticed that all of the extension
keywords I've come accross reciently have had 2 leading underscores
__declspec.


Rob.
--
http://www.victim-prime.dsl.pipex.com/