leading underscore for member names

[Walter Tross]

Somebody with a very regulatory mind in this newsgroup has written
that it's better not to use a leading underscore for class member
names, because names with a leading underscore are used internally by
compilers (well, not so internally, since they appear in header
files).
I personally use the leading underscore (followed by a lower case
letter), which I consider to be much more readable than the trailing
underscore.
My reasoning is that scope resolution works, and if I should get a
clash with a macro (very unlikely, since macros are usually uppercase)
it almost certainly would result in something which won't compile
(could in exceptional cases cause a nuisance when porting to another
platform, but compared with other nuisances...)
Am I wrong?

 

[Cy Edmunds]

Somebody with a very regulatory mind in this newsgroup has written
that it's better not to use a leading underscore for class member
names, because names with a leading underscore are used internally by
compilers (well, not so internally, since they appear in header
files).
I personally use the leading underscore (followed by a lower case
letter), which I consider to be much more readable than the trailing
underscore.
My reasoning is that scope resolution works, and if I should get a
clash with a macro (very unlikely, since macros are usually uppercase)
it almost certainly would result in something which won't compile
(could in exceptional cases cause a nuisance when porting to another
platform, but compared with other nuisances...)
Am I wrong?

Two leading underscores or a leading underscore followed by a capital letter
are reserved. But one leading underscore followed by a lower case letter
should be OK. I used to use a leading underscore myself but changed to m_
when I found out that the "m" meant "member" and not "Microsoft".

 

[Sumit Rajan]

Somebody with a very regulatory mind in this newsgroup has written
that it's better not to use a leading underscore for class member
names, because names with a leading underscore are used internally by
compilers (well, not so internally, since they appear in header
files).

I personally use the leading underscore (followed by a lower case
letter), which I consider to be much more readable than the trailing
underscore.

My reasoning is that scope resolution works, and if I should get a
clash with a macro (very unlikely, since macros are usually uppercase)
it almost certainly would result in something which won't compile
(could in exceptional cases cause a nuisance when porting to another
platform, but compared with other nuisances...)
Am I wrong?

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.165)



165) Such names are also reserved in namespace ::std (17.4.3.1).



Regards,

Sumit.

 

[John Harrison]

Somebody with a very regulatory mind in this newsgroup has written
that it's better not to use a leading underscore for class member
names, because names with a leading underscore are used internally by
compilers (well, not so internally, since they appear in header
files).
I personally use the leading underscore (followed by a lower case
letter), which I consider to be much more readable than the trailing
underscore.
My reasoning is that scope resolution works, and if I should get a
clash with a macro (very unlikely, since macros are usually uppercase)
it almost certainly would result in something which won't compile
(could in exceptional cases cause a nuisance when porting to another
platform, but compared with other nuisances...)
Am I wrong?

I use them for the same reason. And you're not wrong provided you stick to
class members.

john

 

[Walter Tross]

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.

I dont'quite understand the double underscore thing, since in your
writing there is a space between the two underscores. Does it refer to
a leading AND a trailing underscore or does it refer to two
consecutive underscores (as I guess it does)?
I don't use either, in any case, so this does not affect me, I think.

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

165) Such names are also reserved in namespace ::std (17.4.3.1).

Since I only use the leading underscore for my class members, I'm
safely out of the global namespace, and out of ::std too.

Maybe I should start the "Leading Underscore for Member Names" (LUMN)
movement

Walter

 

[Sumit Rajan]

I dont'quite understand the double underscore thing, since in your
writing there is a space between the two underscores. Does it refer to
a leading AND a trailing underscore or does it refer to two
consecutive underscores (as I guess it does)?
I don't use either, in any case, so this does not affect me, I think.

Greetings!

My guess is the same, too. I guess it should be "__".
The space between the underscores exists in the Standard, too. (All I did
was to copy-and-paste). Maybe it was presented that way for better clarity
in print versions of the Standard.

Since I only use the leading underscore for my class members, I'm
safely out of the global namespace, and out of ::std too.

Maybe I should start the "Leading Underscore for Member Names" (LUMN)
movement

We would need to make LUMN pronunciation-friendly (Or it would become a
crime against humanity: the whole world has to do with a name like TCP/IP)?
Maybe LUMeN would do the trick!


Regards,
Sumit.