AllanW@my-dejanews.com wrote:
...
> linkers were not designed to support Namespaces, class types,
> overloaded functions with the same name, etc.
>
> There are two obvious strategies to deal with the problem. The first
> one is to rewrite the linker.
...
>
> The second one is to find some way to adapt the needs of C++ to
> work with the current linker. One broadly suggested technique (I
> believe it was suggested by Bjarne Stroustrup during the CFront
> days) is to "Mangle" the names into something that C++ can parse,
> yet fits within the existing linker technology. There is no single
> algorithm for this, but it always involves at least one character
> that would not be valid in a C function.

True, except for the part about "always involves at least one
character that would not be a valid C function".  Some vendors write
compilers for systems where they can't rewrite the linker, and the
linker is limited to simple legal C symbol names.  In these
situations, the compiler typically uses some combination of
underscores and datatype abbreviations to encode the function
name and its signature.  (The early cfront-based C++ compilers used
this scheme.)

The drawback of this approach is that all C++ names get mangled into
legal C names; this simply can't be helped given the constraint of
not being able to change the linker.  (Such a name-mangling
algorithm, for example, could mangle the function name
'Namesp::Class::foo(const char *)' into something like
'_6Namesp5Class_3foo_PCc', which is a valid C name.)  One of the
side effects of this approach is that it is possible on these
systems to invoke a C++ function from a C program simply by calling
its mangled C name.

This is also the reason that publically visible C++ identifiers
cannot contain two adjacent underscores (e.g., my__foo).  By
mandating that these kinds of names are illegal, the standard
allows compilers operating under the kind of constraints mentioned
above to have a fighting chance at producing mangled names
(containing two or more adjacnet underscores) that won't conflict
with normal user-defined names.

-- David R. Tribble, dtribble@technologist.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hi All
Can any one of you tell me what "name mangling" is?? Is it something to
do with namespaces ???

Thanks in Advance
Kishore



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kishore Korimilli <kishore@com1.med.usf.edu> writes:

>Can any one of you tell me what "name mangling" is?? Is it something to
>do with namespaces ???

"Name mangling" is a common implementation technique to allow
multiple globally-accessible functions and objects having the
same name to exist in the same program. Example:

void f();
void f(int);
class C {
    void f();
};
namespace N {
    void f(int);
}
template< class T > void f(T);

Here we have five functions with external linkage all named "f".
Two pairs have the same parameter lists, and all of them have the
same return type. C++ requires that all of them be distinct, and
that all of them be callable from anywhere in the program.

Typical object-code formats and linkers distinguish entities by
name. In that case, these five functions must have distinct
names. Typical implementations augment the programmer-assigned
name with an encoding deterministically derived from the
properties of the functions that make them unique.

The encoding must be deterministic so that the compiler will
generate a consistent version of the name for every reference
to it in all parts of the program, no matter what other similar
declarations are seen or not seen. The resulting names are
usually not easy for humans to read, and so are humorously
referred to as "mangled names."

An alternative implementation technique would be to maintain a
map of every external name in the program with a generated
arbitrary name for the linker to use.

More advanced systems might allow type and scope information to
be present for names in the object code. In that case, the
names of entities need not be mangled.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36CDDC35.657A050F@com1.med.usf.edu>, Kishore Korimilli
<kishore@com1.med.usf.edu> writes
>i All
>Can any one of you tell me what "name mangling" is?? Is it something to
>do with namespaces ???

No (except that namespace information has to be included in the mangle).
Name-mangling refers to a technique for encoding information about the
parameter types, return values and scope of a declared name which can be
used by the linker to distinguish things with the same declarative name
though they are different.

For example, there has to be a mechanism whereby the compiler can record
the selected function from an overload set so that the linker will link
in the correct implementation.

Name mangling is purely a a compiler implementors technique for
resolving the problem that a name may be used in different ways or
contexts to refer to different things.  There is no requirement that
this be the way that the problem is solved.  However you will find
language experts comment on whether a particular property will form part
of the mangle.  What they mean is whether the property is relevant to
providing correct linkage.

The standard does not legislate on name-mangling algorithms, nor should
it.  Doing so would inhibit creative development of compilation
techniques the result is that object files created with different name-
mangling algorithms will not link correctly.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <YSvz44A0Phz2EwLO@robinton.demon.co.uk>,
  Francis Glassborow <francisG@robinton.demon.co.uk> wrote:
>
> In article <36CDDC35.657A050F@com1.med.usf.edu>, Kishore Korimilli
> <kishore@com1.med.usf.edu> writes
> >i All
> >Can any one of you tell me what "name mangling" is?? Is it something to
> >do with namespaces ???
>
> No (except that namespace information has to be included in the mangle).
> Name-mangling refers to a technique for encoding information about the
> parameter types, return values and scope of a declared name which can be
> used by the linker to distinguish things with the same declarative name
> though they are different.
>
> For example, there has to be a mechanism whereby the compiler can record
> the selected function from an overload set so that the linker will link
> in the correct implementation.
>
> Name mangling is purely a a compiler implementors technique for
> resolving the problem that a name may be used in different ways or
> contexts to refer to different things.  There is no requirement that
> this be the way that the problem is solved.  However you will find
> language experts comment on whether a particular property will form part
> of the mangle.  What they mean is whether the property is relevant to
> providing correct linkage.
>
> The standard does not legislate on name-mangling algorithms, nor should
> it.  Doing so would inhibit creative development of compilation
> techniques the result is that object files created with different name-
> mangling algorithms will not link correctly.

This is all correct, but I thought an example might help to clarify
the issue.

Suppose a C++ program includes all of these declarations, possibly
defined in different translation units:

    namespace NS1 {
        struct Foo {
            int Bar(int,int);
            float Bar(float,float);
            double Bar(double,double);
        };
    };
    namespace NS2 {
        struct Foo {
            int Bar(int,int);
            float Bar(float,float);
            double Bar(double,double);
        };
    };
    int main() {
        NS1::Foo baz;
        NS2::Foo bletch;
        return baz.Bar(1,2) + bletch.Bar(2,1);
    }

First, main() calls two constructors: NS1::Foo::Foo and NS2::Foo::Foo.
Next, it calls NS1::Foo::Bar(int,int) and NS2::Foo::Bar(int,int), both
of which return ints. Finally it calls two destructors: NS1::Foo::~Foo
and NS2::Foo::~Foo.

Imagine trying to link this program with a linker originally created
for use with Fortran, C, and COBOL. How will the linker differentiate
between NS1::Foo::Bar(int,int) and NS2::Foo::Bar(double,double)? These
linkers were not designed to support Namespaces, class types,
overloaded functions with the same name, etc.

There are two obvious strategies to deal with the problem. The first
one is to rewrite the linker. If "NS1::Foo::Bar(int,int)" is a legal
function name, then no problem exists. One thing that makes this
difficult to implement is the fact that we might need to make
corresponding changes to other programs, such as debuggers, library
maintainence programs, and compilers for Fortran, C, and COBOL. Since
users won't buy all of these packages at once, we may need to support
backwards compatibility... it soon gets quite hairy.

The second one is to find some way to adapt the needs of C++ to
work with the current linker. One broadly suggested technique (I
believe it was suggested by Bjarne Stroustrup during the CFront
days) is to "Mangle" the names into something that C++ can parse,
yet fits within the existing linker technology. There is no single
algorithm for this, but it always involves at least one character
that would not be valid in a C function. For instance, Microsoft
Visual C++ 5.0 turns NS1::Foo::Bar(int,int) into
    ?Bar@Foo@NS1@@QAEHHH@Z:NEAR
Somewhere in that near-gibberish, Microsoft also encoded the return
type of the function (int). This detects one particular type of
error that might otherwise be very hard to detect; if two different
translation units declare the same function with two different return
types, I will get an undefined global symbol error.

The words "name mangling" imply something more than was originally
intended; mangling seems unintentional and erroneous. I have seen
more and more literature refer to this as "name decoration" instead.

This technique works well enough that almost every major manufacturer
has adopted it. Which is perhaps unfortunate, because the technique
is not without it's problems. In an environment where the OS allows
multiple programs to share memory, the biggest problem becomes
apparent: Functions compiled with Vendor A's compiler have a tough
time trying to call C++ functions compiled with Vendor B's compiler,
if they use different decoration algorithms. Other problems are
more minor; for instance, maps and symbol lists typically must have
two name columns, one for the mangled name (which is required to
call the function from another language) and another with the original
C++ name (not always available, depending on how recent the linker is.)

Someday linkers will be redesigned to accept fully-formed names
without this decoration, and the whole concept will be obsolete, along
with it's associated problems. However, that day will not be soon
enough for my taste.

----
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <7as77b$fci$1@nnrp1.dejanews.com>,  <AllanW@my-dejanews.com> wrote:
>This technique works well enough that almost every major manufacturer
>has adopted it. Which is perhaps unfortunate, because the technique
>is not without it's problems. In an environment where the OS allows
>multiple programs to share memory, the biggest problem becomes
>apparent: Functions compiled with Vendor A's compiler have a tough
>time trying to call C++ functions compiled with Vendor B's compiler,
>if they use different decoration algorithms.

This can actually be a feature.  There are other aspects of C++ that aren't
specified by the standard, such as vtables and class layout.  If the two
compilers used the same decoration algorithm but different virtual function
call designs, the functions would link but they'd do the wrong thing when
they tried to call each other.

If two compiler implementors want to be able to interoperate, they'll need
to agree on all these low-level details that are outside the scope of the
standard.  It could be something that would be specified by the OS vendor,
as part of their ABI (just as they might already specify C calling
sequences, struct layout, etc).  Ideally, one should be able to assume that
a successful link implies that full binary interoperability is intended.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]