🚀 go-pugleaf

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