underscores in class member names

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:
....
};

re: underscores in class member names

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

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.
[color=blue]
> 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,[/color]

That's quite common practise.
[color=blue]
> 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:
> ....
> };[/color]

I think those shold be fine.

re: underscores in class member names

"BRIAN VICKERY" <islandhaole@verizon.net> wrote in message
news:LKuSb.110$9p5.82@nwrddc02.gnilink.net...[color=blue]
> I've heard that some compilers reserve the '_' starting a symbol for[/color]
system[color=blue]
> variables/symbols. I can not find this documented anywhere (so far).[/color]
I've[color=blue]
> 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:
> ....
> };[/color]


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.

re: underscores in class member names

BRIAN VICKERY wrote in news:LKuSb.110$9p5.82@nwrddc02.gnilink.net:
[color=blue]
> 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:
> ....
> };
>[/color]

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/

re: underscores in class member names

"Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
[color=blue]
>
> 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*[/color]
identifiers[color=blue]
> 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[/color]
using a[color=blue]
> reserved identifier anyway, so I'd suggest m_baz or some such thing.
>[/color]

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

re: underscores in class member names

"Jonathan Turkanis" <technews@kangaroologic.com> wrote in message
news:bved3v$q8s8r$1@ID-216073.news.uni-berlin.de...[color=blue]
>[/color]
[color=blue]
> Why do you prefer (i)? Is this known to be the correct[/color]
interpretation?

I meant (ii) here.

Jonathan

re: underscores in class member names

On Fri, 30 Jan 2004 16:29:49 +0100, Rolf Magnus <ramagnus@t-online.de>
wrote:
[color=blue]
>BRIAN VICKERY wrote:
>[color=green]
>> I've heard that some compilers reserve the '_' starting a symbol for
>> system variables/symbols.[/color][/color]

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
NoSpamPlease@Home.com

re: underscores in class member names

Jonathan Turkanis wrote in news:bved3v$q8s8r$1@ID-216073.news.uni-
berlin.de:
[color=blue][color=green]
>> 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[/color]
> using a[color=green]
>> reserved identifier anyway, so I'd suggest m_baz or some such thing.
>>[/color]
>
> 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,
>[/color]

This would be the same as reserved ... everywhere. The "must be global"
would be unnessasery additional info'.
[color=blue]
> or
>
> (ii) reserved to the implementation if used in the global namespace
>[/color]

[from elswhere]
[color=blue]
> I meant (ii) here.[/color]
[color=blue]
> Why do you prefer (i)? Is this known to be the correct interpretation?
>[/color]

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/

re: underscores in class member names

Rob Williscroft <rtw@freenet.REMOVE.co.uk> wrote in message news:<Xns9480A10CB54DukcoREMOVEfreenetrtw@195.129. 110.201>...[color=blue]
> BRIAN VICKERY wrote in news:LKuSb.110$9p5.82@nwrddc02.gnilink.net:
>[color=green]
> > 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:
> > ....
> > };
> >[/color]
>
> Am identifier with single leading undersore is reserved for the
> implementation if:
>
> Its followed by an uppercase letter (anywhere).[/color]

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

re: underscores in class member names

Graham Dumpleton wrote in news:dc6f5c99.0401301624.544b4b2
@posting.google.com:
[color=blue]
>
> 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.
>[/color]

yes also things like _far, _near, _try all of which are extemsion
keywords
[color=blue]
> Thus, regardless of what the standard for C++ says, don't necessarily
> expect Microsoft to adhere to it. :-)
>[/color]

Well did MS introduce the keyword before or after the standard
came out (1998). 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/

re: underscores in class member names

"Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
[color=blue][color=green]
> >
> > "reserved to the implementation for use as a name in the[/color][/color]
global[color=blue][color=green]
> > namespace"
> >
> > could mean:
> >
> > (i) reserved to the implementation; also, must be global,
> >[/color]
>
> This would be the same as reserved ... everywhere. The "must be[/color]
global"[color=blue]
> would be unnessasery additional info'.
>[/color]

Unnecessary info for users, maybe, but not for implementers.

Maybe you mean it would be an 'unneccessary additional restriction'?
Are you sure that C++ doesn't have any of these? ;-)

Jonathan

re: underscores in class member names

Jonathan Turkanis wrote in news:bvf1qq$s3oii$1@ID-216073.news.uni-
berlin.de:
[color=blue]
>
> "Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
>[color=green][color=darkred]
>> >
>> > "reserved to the implementation for use as a name in the[/color][/color]
> global[color=green][color=darkred]
>> > namespace"
>> >
>> > could mean:
>> >
>> > (i) reserved to the implementation; also, must be global,
>> >[/color]
>>
>> This would be the same as reserved ... everywhere. The "must be[/color]
> global"[color=green]
>> would be unnessasery additional info'.
>>[/color]
>
> Unnecessary info for users, maybe, but not for implementers.[/color]

How would it help an implementer, the standard tells implementors
what they have to implement not *how*, "must be global" could
only be related to how.
[color=blue]
>
> Maybe you mean it would be an 'unneccessary additional restriction'?[/color]

It isn't a restriction, its saying that _lowercase *must* be a global
namespace identifier, i.e. its telling an implementor some details
about *how* to implement.

[snip]

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

re: underscores in class member names

"Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
[color=blue][color=green][color=darkred]
> >> This would be the same as reserved ... everywhere. The "must be[/color]
> > global"[color=darkred]
> >> would be unnessasery additional info'.
> >>[/color]
> >
> > Unnecessary info for users, maybe, but not for implementers.[/color]
>
> How would it help an implementer, the standard tells implementors
> what they have to implement not *how*, "must be global" could
> only be related to how.
>[/color]

Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
constitutes necessary information for implementers.
[color=blue][color=green]
> >
> > Maybe you mean it would be an 'unneccessary additional[/color][/color]
restriction'?[color=blue]
>
> It isn't a restriction, its saying that _lowercase *must* be a[/color]
global[color=blue]
> namespace identifier, i.e. its telling an implementor some details
> about *how* to implement.
>[/color]

What distinction are you trying to make? I don't see how a requirement
that such identifiers -- if used by an implementation -- must be
global, isn't a restriction. True, the standard tries to give
implementers broad discretion, yet it also puts quite a few
constraints on implementations.

Maybe you should try to find some evidence in favor of your
interpretation. I never said it was wrong, by the way. I just asked
you to support it.

Jonathan

re: underscores in class member names

Jonathan Turkanis wrote in news:bvf3rp$rl73d$1@ID-216073.news.uni-
berlin.de:
[color=blue]
>
> "Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
>[color=green][color=darkred]
>> >> This would be the same as reserved ... everywhere. The "must be
>> > global"
>> >> would be unnessasery additional info'.
>> >>
>> >
>> > Unnecessary info for users, maybe, but not for implementers.[/color]
>>
>> How would it help an implementer, the standard tells implementors
>> what they have to implement not *how*, "must be global" could
>> only be related to how.
>>[/color]
>
> Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
> constitutes necessary information for implementers.[/color]

My apologees, I should have consulted the standard when you first said:
[color=blue]
>
> 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,
>[/color]

This section (17.4.3) is describing constraints on programmes.
However your rewording with hindsight appears to be as if your reading
the section as constraining implementation's.
[color=blue]
>[color=green][color=darkred]
>> >
>> > Maybe you mean it would be an 'unneccessary additional[/color][/color]
> restriction'?[color=green]
>>
>> It isn't a restriction, its saying that _lowercase *must* be a[/color]
> global[color=green]
>> namespace identifier, i.e. its telling an implementor some details
>> about *how* to implement.
>>[/color]
>
> What distinction are you trying to make? I don't see how a requirement
> that such identifiers -- if used by an implementation -- must be
> global, isn't a restriction.[/color]

Indeed, implementors arn't allowed to use _lowercase identifiers
other than in the global namespace (or in std).

I interpreted you originaly as suggesting *nobody* could use such
identifiers other than in the global namespace and only
implementors can use them there.
[color=blue]
> True, the standard tries to give
> implementers broad discretion, yet it also puts quite a few
> constraints on implementations.
>
> Maybe you should try to find some evidence in favor of your
> interpretation. I never said it was wrong, by the way. I just asked
> you to support it.
>[/color]

There is only one peice evidence available, I presume since you
quoted from it, that you've read it. It helps if you read the all
of "17.4.3 Constraints on programs", here's the relevent quote:

17.4.3.1.2 Global names
1 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).

The second bullet is clearly saying that implementation's can use
identifiers such as _lowercase at in the global namespace so
a conforming programme may not.

The note 165) tells us we can't put such identifiers in namespace std
but we can't do that anyway.

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

re: underscores in class member names

On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
<technews@kangaroologic.com> wrote in comp.lang.c++:
[color=blue]
>
> "Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
>[color=green]
> >
> > 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*[/color]
> identifiers[color=green]
> > 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[/color]
> using a[color=green]
> > reserved identifier anyway, so I'd suggest m_baz or some such thing.
> >[/color]
>
> 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[/color]

Your confusion, and this wording, is caused by C++ adopting a C
restriction but applying new terminology.

C reserves the leading underscore+upper case, and leading double
underscore (but not embedded double underscore, that's a C++ addition)
in all contexts.

Then it reserves leading underscore+lower case at file scope. The
problem with C++ duplicating this restriction is... there is NO SUCH
THING as "file scope" in the standard C++. The phrase literally does
not exist in the standard.

What is file scope in C has been expanded into the concept of
namespace scope in C++. Things that are defined or declared outside
of a function in C++ are either inside a (named or anonymous)
namespace, concepts that do not exist in C, or they are at the top
level, what C calls "file scope" and C++ calls the global namespace.

Note that it makes no difference whether the "file scope"/"global
namespace" identifiers have external linkage or not, even with
internal linkage they can conflict with things the compiler defines in
its header files, or even pre-defined helper functions that it calls
directly.

Don't confuse the global namespace in C++ with the concept of global
variables. It really means pretty much exactly the same thing as file
scope in C.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

re: underscores in class member names

"Jack Klein" <jackklein@spamcop.net> wrote in message
news:lham10l8015imrkqvt65psokhd1q1f0oq3@4ax.com...[color=blue]
> On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
> <technews@kangaroologic.com> wrote in comp.lang.c++:
>[color=green]
> >
> > "Rob Williscroft" <rtw@freenet.REMOVE.co.uk> wrote in message:
> >[color=darkred]
> > >
> > > 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*[/color]
> > identifiers[color=darkred]
> > > 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[/color][/color][/color]
it[color=blue][color=green][color=darkred]
> > > *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[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > remember all the rules, so they will probably complain that your[/color]
> > using a[color=darkred]
> > > reserved identifier anyway, so I'd suggest m_baz or some such[/color][/color][/color]
thing.[color=blue][color=green][color=darkred]
> > >[/color]
> >
> > I'm familiar with the language from the standard, but it sounds a[/color][/color]
bit[color=blue][color=green]
> > ambiguous:
> >
> > "reserved to the implementation for use as a name in the[/color][/color]
global[color=blue][color=green]
> > namespace"
> >
> > could mean:
> >
> > (i) reserved to the implementation; also, must be global,
> >
> > or
> >
> > (ii) reserved to the implementation if used in the global[/color][/color]
namespace[color=blue][color=green]
> >
> > Why do you prefer (i)? Is this known to be the correct[/color][/color]
interpretation?[color=blue][color=green]
> >
> > Jonathan[/color]
>
> Your confusion, and this wording, is caused by C++ adopting a C
> restriction but applying new terminology.
>
> C reserves the leading underscore+upper case, and leading double
> underscore (but not embedded double underscore, that's a C++[/color]
addition)[color=blue]
> in all contexts.
>
> Then it reserves leading underscore+lower case at file scope. The
> problem with C++ duplicating this restriction is... there is NO SUCH
> THING as "file scope" in the standard C++. The phrase literally[/color]
does[color=blue]
> not exist in the standard.
>
> What is file scope in C has been expanded into the concept of
> namespace scope in C++. Things that are defined or declared outside
> of a function in C++ are either inside a (named or anonymous)
> namespace, concepts that do not exist in C, or they are at the top
> level, what C calls "file scope" and C++ calls the global namespace.
>
> Note that it makes no difference whether the "file scope"/"global
> namespace" identifiers have external linkage or not, even with
> internal linkage they can conflict with things the compiler defines[/color]
in[color=blue]
> its header files, or even pre-defined helper functions that it calls
> directly.
>
> Don't confuse the global namespace in C++ with the concept of global
> variables. It really means pretty much exactly the same thing as[/color]
file[color=blue]
> scope in C.[/color]

Thank you for your historical perspective. I don't believe I was
confusing global variables with the global namespace. I was using
'global' as shorthand for 'in the global namespace' because we were
focusing on a different issue. The question was whether member
variable names with single leading underscores not followed by an
uppercase letter are legal in user code.

Looking at the second item of 17.4.3.1.2/1,

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

I noted that there was a plausible reading according to which such a
use would be prohibited. Namely, it could be held to say that such
names are reserved for use by the implementation -- so that they
cannot be used at all in user code -- and *additionally* the
implementation must use such names, if it choses to use them at all,
in the global namespace.

Jonathan

re: underscores in class member names

> Certain sets of names and function signatures are always reserved to the[color=blue]
> 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.[/color]

Can someone explain to me *what* or *who* is or qualifies as an
implementation? For example, SGI's STL library contains _Uppercase and
__doubleunder names. Why does the SGI company or programmer in SGI
have the right to be an *implementation* but I do not? Why are not my
libraries just as *implementation* worthy as any other programmer.

Also, can someone explain to me by what mechanisms (besides a macro)
the use of these underscores names within a class or namespace I
create can conflict with a C++ implementation.

re: underscores in class member names

Keith H Duggar wrote:
[color=blue]
> Can someone explain to me *what* or *who* is or qualifies as an
> implementation? For example, SGI's STL library contains _Uppercase and
> __doubleunder names. Why does the SGI company or programmer in SGI
> have the right to be an *implementation* but I do not? Why are not my
> libraries just as *implementation* worthy as any other programmer.[/color]

What does the S in STL stand for?
[color=blue]
> Also, can someone explain to me by what mechanisms (besides a macro)
> the use of these underscores names within a class or namespace I
> create can conflict with a C++ implementation.[/color]

typedef int __doubleunder;

std::vector<int> yo;

Pretend that std::vector depended on a variable called __doubleunder, but
your typedef made its usage look like a type.

(I'm stuck on this one too - just don't do it!)

--
Phlip
http://www.xpsd.org/cgi-bin/wiki?Tes...UserInterfaces

re: underscores in class member names

Keith H Duggar wrote:
[color=blue][color=green]
>> 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.[/color]
>
> Can someone explain to me *what* or *who* is or qualifies as an
> implementation?[/color]

Anything that implements the (or part of the) C++ standard.
[color=blue]
> For example, SGI's STL library contains _Uppercase and
> __doubleunder names. Why does the SGI company or programmer in SGI
> have the right to be an *implementation* but I do not?[/color]

Probably because they are implementing the standard library (which is
part of C++ and thus part of an implementation of it) and you don't.
[color=blue]
> Why are not my libraries just as *implementation* worthy as any other
> programmer.[/color]

They are not implementations of the standard.
[color=blue]
> Also, can someone explain to me by what mechanisms (besides a macro)
> the use of these underscores names within a class or namespace I
> create can conflict with a C++ implementation.[/color]

One example is the name mangling. In C++, several functions with the
same name can exist in different namespaces or as members of different
classes or just as overloads with different number and types of
arguments. So there is typically a scheme that translates those
function names to internal names that contain all that information so
the linker can find the functions. Those internal names are often such
reserved names, so if you use those, they can conflict with other code.

re: underscores in class member names

Rolf Magnus wrote:
[color=blue][color=green]
>> Also, can someone explain to me by what mechanisms (besides a macro)
>> the use of these underscores names within a class or namespace I
>> create can conflict with a C++ implementation.[/color]
>
> One example is the name mangling. In C++, several functions with the
> same name can exist in different namespaces or as members of different
> classes or just as overloads with different number and types of
> arguments. So there is typically a scheme that translates those
> function names to internal names that contain all that information so
> the linker can find the functions. Those internal names are often such
> reserved names, so if you use those, they can conflict with other
> code.[/color]

Just for a practical example of this. You can't produce an executable
from the following code with e.g. g++ 3.3.2:

int _Z4testv;

void test() {};

int main()
{
test();
}

The reason is that the internal mangled name for the function test is
_Z4testv, so there is a naming conflict with the global variable. The
error message looks like this:

/tmp/cckaLQYy.s: Assembler messages:
/tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined

re: underscores in class member names

Thanks for the example Rolf.
[color=blue]
> int _Z4testv;
>
> void test() {};
>
> int main()
> {
> test();
> }
>
> The reason is that the internal mangled name for the function test is
> _Z4testv, so there is a naming conflict with the global variable. The
> error message looks like this:
>
> /tmp/cckaLQYy.s: Assembler messages:
> /tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined[/color]

Personally, I never pollute the global namespace with underscore
names. I was mainly thinking of continuing to use __xyz to indicate
member variables. I tried using m_xyz for a while but the code didn't
look nearly as nice as with __xyz. Also, I tried using xyz_ as many
suggest but again __xyz was much easier on my eyes and I take it that
xyz__ would also be reserved (double underscore) is that correct?

However, your example seems to indicate that I could run into name
mangling problems even within a class namespace.

Thank you again, I will have to look into this more.

PS. What convention to you use for member variable names?

re: underscores in class member names

On 31 Jan 2004 18:31:56 -0800, duggar@mit.edu (Keith H Duggar) wrote:
[color=blue]
>Personally, I never pollute the global namespace with underscore
>names. I was mainly thinking of continuing to use __xyz to indicate
>member variables. I tried using m_xyz for a while but the code didn't
>look nearly as nice as with __xyz. Also, I tried using xyz_ as many
>suggest but again __xyz was much easier on my eyes and I take it that
>xyz__ would also be reserved (double underscore) is that correct?
>
>However, your example seems to indicate that I could run into name
>mangling problems even within a class namespace.[/color]

Don't forget that although your member names are within a namespace,
the ones we have been talking about often are not, so there is still
plenty of opportunity for clashes.


--
Bob Hairgrove
NoSpamPlease@Home.com

re: underscores in class member names

Keith H Duggar wrote:
[color=blue]
> Thanks for the example Rolf.
>[color=green]
>> int _Z4testv;
>>
>> void test() {};
>>
>> int main()
>> {
>> test();
>> }
>>
>> The reason is that the internal mangled name for the function test is
>> _Z4testv, so there is a naming conflict with the global variable. The
>> error message looks like this:
>>
>> /tmp/cckaLQYy.s: Assembler messages:
>> /tmp/cckaLQYy.s:13: Error: symbol `_Z4testv' is already defined[/color]
>
> Personally, I never pollute the global namespace with underscore
> names. I was mainly thinking of continuing to use __xyz to indicate
> member variables. I tried using m_xyz for a while but the code didn't
> look nearly as nice as with __xyz. Also, I tried using xyz_ as many
> suggest but again __xyz was much easier on my eyes and I take it that
> xyz__ would also be reserved (double underscore) is that correct?[/color]

Yes. Everything that contains two consecutive underscores, so both __xyz
and xyz__ are reserved.
[color=blue]
> However, your example seems to indicate that I could run into name
> mangling problems even within a class namespace.[/color]

I'm not sure how likely it is that you can get into problems with your
above naming scheme, but my example at least shows that there might be
things you haven't been considering. I don't know of other internal
uses of reserved identifiers than standard library macros and name
mangling, but that doesn't mean there are none, and it also will depend
on the compiler. The simplest way to be sure still is by just not using
reserved identifiers.
[color=blue]
> Thank you again, I will have to look into this more.
>
> PS. What convention to you use for member variable names?[/color]

xyz_