🚀 go-pugleaf

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