> I certainly hope not!  Name mangling is a solution to passing type
> information to 1950's linkers.  Once linkers become more sophisticated,
> name mangling can disappear back into the slime from which it came.

I beg to differ.  Name mangling serves several indispensible functions:

1.  It makes it possible to have more than one function with the same name
(differing in their argument lists).  To do this without mangling, the linker
would have to see not just a function name, or even class::name, but a full
_prototype_ for each function (omitting variable names and the result type).

2.  It allows the linker to do error checking.  Example:  Module A calls
foo() in module B.  I change the definition of foo (and its argument list)
but forget to change A.  Without name mangling, the program will simply crash
(or do strange things because I've clobbered the stack...)

On systems like the PC, with multiple pointer formats, this could also be
used to check that all modules (including library code) were compiled with
the same (or compatible) memory model.  I think it is really stupid that none
of the compilers for the PC makes this possible by including the memory model
in mangled names.

3.  When linking with other languages such as Pascal, it in effect checks that
you told the C++ compiler to use the calling sequence for the language that
the function you're calling is in.

In short, wanting to eliminate name mangling is like wanting a compiler that
never prints error messages.  It's for people who would rather walk off a
cliff than have someone tell them they're about to.

For the same reason, I'm against the concept of "undefined behavior" in the C
and C++ standards.  No program that has "undefined behavior" should compile.
--
John David Galt                                I do not speak for my employer.
jgalt@infosoft.com      Send personal mail to:  John_David_Galt@cup.portal.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <DL1pqE.KKq@infosoft.com>, jgalt@infosoft.com (John Galt) writes:
--> > I certainly hope not!  Name mangling is a solution to passing type
--> > information to 1950's linkers.  Once linkers become more sophisticated,
--> > name mangling can disappear back into the slime from which it came.
-->
-->I beg to differ.  Name mangling serves several indispensible functions:
-->
-->1.  It makes it possible to have more than one function with the same name
-->(differing in their argument lists).  To do this without mangling, the linker
-->would have to see not just a function name, or even class::name, but a full
-->_prototype_ for each function (omitting variable names and the result type).

...but this is presumably just the kind of thing that the original author
would expect his "more sophisticated" linkers to do!

-->2.  It allows the linker to do error checking.  Example:  Module A calls
-->foo() in module B.  I change the definition of foo (and its argument list)
-->but forget to change A.  Without name mangling, the program will simply crash
-->(or do strange things because I've clobbered the stack...)

...and this!

-->3.  When linking with other languages such as Pascal, it in effect checks that
-->you told the C++ compiler to use the calling sequence for the language that
-->the function you're calling is in.

...and this!

-->For the same reason, I'm against the concept of "undefined behavior" in the C
-->and C++ standards.  No program that has "undefined behavior" should compile.

It is not always possible for the compiler to check for undefined behaviour.
I guess that
    long *p = malloc (sizeof (int));
is undefined behaviour but I don't think a compiler could easily
check it.  And what about:
    free (p);
    *p = 27;
If the two lines are in different source files the compiler really has
very little chance.

It is possible to define a language where all errors are caught at
compile time or run-time.  Such a language wouldn't be C .. or in
the spirit of C.  We systems programmers need to do dodgy things
from time to time and like C because it doesn't get in our way!

I believe that Modula-3 might be such a language, setting aside unsafe
modules (which have to be explicitly marked as such): no "unchecked
errors" can occur in a Modula-3 program.  But note that even here, we're
relying on **runtime** checking, not compile time checking.  Code like
    a : array [10] of integer;
    i: integer;
    read (i);
    a[i] := 0;
cannot be checked at compile time!

-- jP --


---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In message <DL1pqE.KKq@infosoft.com> - jgalt@infosoft.com (John Galt) writes:

:>> I certainly hope not!  Name mangling is a solution to passing type
:>> information to 1950's linkers.  Once linkers become more sophisticated,
:>> name mangling can disappear back into the slime from which it came.
:>
:>I beg to differ.  Name mangling serves several indispensible functions:

:>In short, wanting to eliminate name mangling is like wanting a compiler that
:>never prints error messages.  It's for people who would rather walk off a
:>cliff than have someone tell them they're about to.

Yes, but linkers should hide the fact that names are mangled by only printing
the unmangled version.  The user should NEVER see the mangled names
but should see the "declaration" instead.

Linkers should also NOT limit the name lengths but I expect this to fade away
eventually.

Ken Walter

* All the above is hearsay and the opinion of nobody in particular
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

John Galt (jgalt@infosoft.com) wrote:
: > I certainly hope not!  Name mangling is a solution to passing type
: > information to 1950's linkers.  Once linkers become more sophisticated,
: > name mangling can disappear back into the slime from which it came.
:
: I beg to differ.  Name mangling serves several indispensible functions:
:
: 1.  It makes it possible to have more than one function with the same name
: (differing in their argument lists).  To do this without mangling, the linker
: would have to see not just a function name, or even class::name, but a full
: _prototype_ for each function (omitting variable names and the result type).

Why is this a problem ?  The *existing* name mangling schemes now in use
carry around all of the information in the prototype (in encoded form).
The only change from a "name mangling" system to an "intelligent linker"
system would be that the object module format recognised by the linker
would have special records to store the function signature information,
rather than storing that information in the name of the function.

In other words, your implication that eliminating name mangling would
require *more* information to be passed to the linker is plainly untrue.

: On systems like the PC, with multiple pointer formats, this could also be
: used to check that all modules (including library code) were compiled with
: the same (or compatible) memory model.  I think it is really stupid that none
: of the compilers for the PC makes this possible by including the memory model
: in mangled names.

What PC C++ implementations have you been using ?  All of the ones that I
use (that support 16:32 pointers in addition to 0:32 pointers) include
far/near qualifications as part of the mangling scheme :

MetaWare High C++
-----------------
void n ( char * p )  -> n@qpc$v
void n ( char _Far * p ) -> n@qpzfzc$v

Watcom C++
----------
void n ( char * p )  -> W?n$n(pna)v
void n ( char __far * p ) -> W?n$n(pfa)v

In other words, "quality of implementation".  Use a better implementation.
Try one of the above two if you like.
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]