🚀 go-pugleaf

Theodore Papadopoulo <papadop@sophia.inria.fr> writes:

>First, it seems that I have not understood all of the rationale behind
>mangling scheme... I understand very well why names have to be encoded
>(althougth I do not understand at all why the return type is not a part
>of the encodind scheme). I understand very well too that object's
>implementation may vary form one compiler to an another so that the
>objects (.o) produced by different compilers should be uncompatible. But
>why having chosen to make this incompatibility through different
>mangling schemes... Wouldn't have it be much more easy to say that in
>each (.o) file is introduced an undefined symbol containing an
>identification of the compiler and of the version of the mangling scheme
>(something like __G++_MANGLING_2.3 or __ARM_MANGLING_1.4).

One problem I see with this is that it would impose a small space penalty,
since each object file would have to contain space for this symbol.
One word per object file may not sound like much, but there are some
cases where this could be a problem.  Sometimes libraries are carefully
divided (either manually or with some tool) so that each object file
contains only one variable or function, so as to minimize the granularity
of the linking process, and to avoid the cascading library effect where
you use one function from an object file, and that object file contains
another function (which you don't use) that needs another object file,
which contains functions that need other object files, etc.
If each object file contains only one variable or function, then
adding one word per object file may be a significant overhead.

With linker support, this can be avoided -- but then again with full
linker support, we could have type-safe linkage without name mangling!
I don't know of any portable way of forcing a link error if a symbol
is not defined without using up space in the object file.

The other problem I see is that it might make changes to the name
mangling scheme more painful.  Currently, if a C++ vendor realizes that
for some obscure case they need to change the name mangling (perhaps
because they need to support some new C++ feature), all they need to do
is fix that obscure case and issue a new release.  Customers who didn't
use that obscure case don't need to recompile.  But if your scheme was
adopted, any change to the name mangling would require all customers to
recompile everything.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
I will have little or no net access from Nov 30 until Dec 25,
so please email me a copy of any follow-ups.

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