underscores in class member names

Discussion in 'C++' started by BRIAN VICKERY, Jan 30, 2004.

  1. 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, Jan 30, 2004
    #1
    1. Advertising

  2. BRIAN VICKERY

    Rolf Magnus Guest

    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.
     
    Rolf Magnus, Jan 30, 2004
    #2
    1. Advertising

  3. BRIAN VICKERY

    Sumit Rajan Guest

    "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.
     
    Sumit Rajan, Jan 30, 2004
    #3
  4. 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, Jan 30, 2004
    #4
  5. "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, Jan 30, 2004
    #5
  6. "Jonathan Turkanis" <> wrote in message
    news:bved3v$q8s8r$-berlin.de...
    >


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

    interpretation?

    I meant (ii) here.

    Jonathan
     
    Jonathan Turkanis, Jan 30, 2004
    #6
  7. 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
     
    Bob Hairgrove, Jan 30, 2004
    #7
  8. 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, Jan 30, 2004
    #8
  9. 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, Jan 31, 2004
    #9
  10. 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 (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/
     
    Rob Williscroft, Jan 31, 2004
    #10
  11. "Rob Williscroft" <> wrote in message:

    > >
    > > "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'.
    >


    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
     
    Jonathan Turkanis, Jan 31, 2004
    #11
  12. Jonathan Turkanis wrote in news:bvf1qq$s3oii$-
    berlin.de:

    >
    > "Rob Williscroft" <> wrote in message:
    >
    >> >
    >> > "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'.
    >>

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


    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.

    >
    > Maybe you mean it would be an 'unneccessary additional restriction'?


    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/
     
    Rob Williscroft, Jan 31, 2004
    #12
  13. "Rob Williscroft" <> wrote in message:

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

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


    Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
    constitutes necessary information for implementers.

    > >
    > > Maybe you mean it would be an 'unneccessary additional

    restriction'?
    >
    > 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.
    >


    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
     
    Jonathan Turkanis, Jan 31, 2004
    #13
  14. Jonathan Turkanis wrote in news:bvf3rp$rl73d$-
    berlin.de:

    >
    > "Rob Williscroft" <> wrote in message:
    >
    >> >> 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.

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

    >
    > Did I say 'helpful'? I said 'necessary': if (i) is correct, then it
    > constitutes necessary information for implementers.


    My apologees, I should have consulted the standard when you first said:

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

    >
    >> >
    >> > Maybe you mean it would be an 'unneccessary additional

    > restriction'?
    >>
    >> 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.
    >>

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


    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.

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


    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/
     
    Rob Williscroft, Jan 31, 2004
    #14
  15. BRIAN VICKERY

    Jack Klein Guest

    On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
    <> wrote in comp.lang.c++:

    >
    > "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


    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/~ajo/docs/FAQ-acllc.html
     
    Jack Klein, Jan 31, 2004
    #15
  16. "Jack Klein" <> wrote in message
    news:...
    > On Fri, 30 Jan 2004 13:10:19 -0700, "Jonathan Turkanis"
    > <> wrote in comp.lang.c++:
    >
    > >
    > > "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

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


    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
     
    Jonathan Turkanis, Jan 31, 2004
    #16
  17. > 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.


    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.
     
    Keith H Duggar, Jan 31, 2004
    #17
  18. BRIAN VICKERY

    Phlip Guest

    Keith H Duggar wrote:

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


    What does the S in STL stand for?

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


    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?TestFirstUserInterfaces
     
    Phlip, Jan 31, 2004
    #18
  19. BRIAN VICKERY

    Rolf Magnus Guest

    Keith H Duggar wrote:

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

    >
    > Can someone explain to me *what* or *who* is or qualifies as an
    > implementation?


    Anything that implements the (or part of the) C++ standard.

    > 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?


    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.

    > Why are not my libraries just as *implementation* worthy as any other
    > programmer.


    They are not implementations of the standard.

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


    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.
     
    Rolf Magnus, Jan 31, 2004
    #19
  20. BRIAN VICKERY

    Rolf Magnus Guest

    Rolf Magnus wrote:

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

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


    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
     
    Rolf Magnus, Jan 31, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Laura
    Replies:
    1
    Views:
    410
    Laura
    Jun 3, 2004
  2. E11
    Replies:
    1
    Views:
    4,793
    Thomas Weidenfeller
    Oct 12, 2005
  3. Kari Laitinen

    Opinions about underscores in names

    Kari Laitinen, Nov 13, 2003, in forum: C++
    Replies:
    2
    Views:
    339
    Ekkehard Morgenstern
    Nov 13, 2003
  4. Ares Lagae
    Replies:
    8
    Views:
    451
    Ares Lagae
    Sep 24, 2004
  5. James Harris
    Replies:
    46
    Views:
    1,043
    Ronald Landheer-Cieslak
    Jul 23, 2004
Loading...

Share This Page