Is the name mangling mechanism of C++ being standardized (or has it already
been)?  If not, does that mean that object libraries compiled under one
compiler will not be usable under other compilers?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <...> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>
>Is the name mangling mechanism of C++ being standardized (or has it already
>been)?  If not, does that mean that object libraries compiled under one
>compiler will not be usable under other compilers?

No, name mangling has not been standardized, and I think your argument
is the wrong reason for standardization.

There are many other factors that have to be considered if you intend
to link libraries compiled with different compilers: stack layout,
register allocation, standard runtime libraries, object code formats,
and probably much more.  If two compiler vendors solve all these
problems, they will probably also solve name mangling.

However, a unified name mangling scheme would make it easier to port
various C++ tools, such as, browsers and profilers.  Until all
programming tools understand C++ name mangling, it would also make
manual demangling easier.


  -- Dag

>>>>> On 21 Oct 91 09:52:44 GMT, dag@control.lth.se (Dag Bruck) said:

Dag> In article <...> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

David> Is the name mangling mechanism of C++ being standardized (or has it
David> already been)?  If not, does that mean that object libraries compiled
David> under one compiler will not be usable under other compilers?

Dag> No, name mangling has not been standardized, and I think your argument is
Dag> the wrong reason for standardization.

Dag> There are many other factors that have to be considered if you intend
Dag> to link libraries compiled with different compilers: stack layout,
Dag> register allocation, standard runtime libraries, object code formats,
Dag> and probably much more.  If two compiler vendors solve all these
Dag> problems, they will probably also solve name mangling.

All compiler vendors (C++ or not) have to solve this in order to run on a
particular architecture (VMS, UNIX, whatever) and most are able to follow some
standard.  For instance, a C++ compiler for VMS must understand the libraries
already there that were compiled with VMS C.  So, the point is, a typical C++
compiler will solve most of these problems in order to coexist with the
non-C++ environment already in place.  The question still stands as to how
should C++ environments coexist with one another?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <CIMSHOP!DAVIDM.91Oct20114604@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:

> Is the name mangling mechanism of C++ being standardized (or has it already
> been)?  If not, does that mean that object libraries compiled under one
> compiler will not be usable under other compilers?

There has been some discussion of the possibility of standardizing the
name mangling, but so far no one has come up with a proposal that
fits within the limits of what a C++ standard should reasonably cover.

For example, suppose you wanted to write a program that would test
whether a C++ compiler met the proposed standard?  How would you do
that without writing any programs in any language other than C++?
--
    --Andrew Koenig
      ark@europa.att.com

In article <1991Oct21.095244.804@lth.se> dag@control.lth.se (Dag Bruck) writes:
|However, a unified name mangling scheme would make it easier to port
|various C++ tools, such as, browsers and profilers.  Until all
|programming tools understand C++ name mangling, it would also make
|manual demangling easier.

Agreed in theory.  In practice the differences in name mangling schemes
are not just arbitrary differences, but in fact different vendors
are encoding slightly different information in their type names.
One obvious example is that PC vendors needs to encode small verses
large model information into name mangling to be type safe.  The AT&T
scheme doesn't cover that.  Also, note that there never was "one"
name mangling scheme.  There were three -- once there were any name
mangling schemes at all.

>>>>> Regarding Standard Name Mangling?; ark@alice.att.com (Andrew Koenig)
>>>>> adds:

Andrew> For example, suppose you wanted to write a program that would test
Andrew> whether a C++ compiler met the proposed standard?  How would you do
Andrew> that without writing any programs in any language other than C++?

Does using 'extern "C" {}' count?  I would think you could write essentially
two separate modules with (admittedly) a hard-coded check.  The first module
would develop a C++ class of some sort and the second module would attempt to
call a member function of that class by declaring it as extern "C" with the
name already "mangled".  Perhaps a CPP macro could be developed to to the
mangling in a standard way?  (Probably not.)  Think it would work?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <CIMSHOP!DAVIDM.91Oct21101223@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
[regards calling conventions and object models]
|All compiler vendors (C++ or not) have to solve this in order to run on a
|particular architecture (VMS, UNIX, whatever) and most are able to follow some
|standard.  For instance, a C++ compiler for VMS must understand the libraries
|already there that were compiled with VMS C.  So, the point is, a typical C++
|compiler will solve most of these problems in order to coexist with the
|non-C++ environment already in place.

I disagree.  The C++ calling conventions can be completely different than
the C calling conventions, because the C calling conventions can be
distinguished by the extern "C" construct.  Object models can be considerably
different at least distingusihed  on whether there is a vtable pointer or not,
and possibly again by the extern "C" construct.  If some compiler vendors
want to get together and reach agreement on calling conventions, name
mangling, object models, etc -- I say "great!" -- BUT, let's leave code
generation issues out of the issues of language definition.  It's a terrible
mistake to mix up the two, IMHO.  For example, its totally reasonable
for some vendor to want to come up with a highly interactive interpreted
version of C++.  But the code generation issues for such an interpreter
would be totally different that today's compiled code.  So let's keep
language and implementation separate, please!

In article <CIMSHOP!DAVIDM.91Oct20114604@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>Is the name mangling mechanism of C++ being standardized (or has it already
>been)?  If not, does that mean that object libraries compiled under one
>compiler will not be usable under other compilers?

Unfortunately, there are several different name mangling methods now in use.
At Zortech, we've added the function unmangle_ident(char *ident) to the
runtime library. It takes a string, unmangles it to a presentable form,
and returns it. We encourage our customers to use that function, so that
they are insulated from changes in the name mangling scheme.

We encourage other vendors to provide an equivalent function.

(Name mangling schemes aren't the only reason why object libraries are
incompatible between compilers. Things such as calling conventions and
object layouts are different.)

We should remember that name mangling is a hack, imposed on us because
of inferior linker technology.

I hope we will find improved linkers that understand about argument
types, overloading and virtual functions, on many machines -- sometime
in the future.  When that happens, we will have a compatibility problem
with object file formats, but the names wouldn't have to be mangled.

  -- Dag

In article <CIMSHOP!DAVIDM.91Oct20114604@uunet.UU.NET> cimshop!davidm@uunet.UU.NET (David S. Masterson) writes:
>Is the name mangling mechanism of C++ being standardized (or has it already
>been)?  If not, does that mean that object libraries compiled under one
>compiler will not be usable under other compilers?

 The issues presented in attempting to make object libraries usable
with other compilers run much deeper than any differences in name mangling.
Making object libraries interchangeable would require standardizing the
layout of objects, calling conventions, and virtual function call mechanisms.
So, even if name mangling were standardized, it wouldn't guarantee that
object libraries could be interchanged.
 Name mangling is one technique for implementing typesafe linkage.
Standardizing it would severely constrain compiler implementors who would
like to handle typesafe linkage in a different way.
 -- Pete

>>>>> On 25 Oct 91 20:12:58 GMT, bright@nazgul.UUCP (Walter Bright) said:

Walter> In article <ROBERTK.91Oct22200111@rkrajewski.lotus.com> robertk@rkrajewski.lotus.com (Robert Krajewski) writes:

Robert> However, it would be nice if there were portable *functions* to mangle
Robert> and unmangle function names.

Walter> Zortech C++ provides a function to unmangle names as part of its
Walter> standard library.

Curiousity question:

Do these "demanglers" have any use beyond debugging?
--
====================================================================
David Masterson     Consilium, Inc.
(415) 691-6311     640 Clyde Ct.
uunet!cimshop!davidm    Mtn. View, CA  94043
====================================================================
"If someone thinks they know what I said, then I didn't say it!"

In article <0s+d5c=@microsoft.UUCP>, jimad@microsoft.UUCP (Jim ADCOCK) writes:
|> ....     The C++ calling conventions can be completely different than
|> the C calling conventions, because the C calling conventions can be
|> distinguished by the extern "C" construct.


Since I have been bit by this, I have to pick a nit here.  extern "C"
is NOT powerful enough to fully support different calling conventions
between C++ and C.  Because `extern "C"' is a storage class and not a
type modifier, you cannot declare a `pointer to C function' as opposed
to a `pointer to C++ function'.

Zortech attempts to get around this by making any function pointer
parameter to an extern "C" function `extern "C"' as well.  But this
still doesn't allow passing C function pointers to C++ functions and
vice versa.  The `pascal' keyword that some DOS C compiler use is a
much better solution to this problem.

    Peter Moore
    peter@objy.com