🚀 go-pugleaf

As a user of (at least) two different C++ compilers, here are a couple
of questions for which I would be pleased to have answers. My first
concern here is not directly the C++ langage but merely the effects of
the standard choices onto the programming environment and more
specifically onto the debugger.

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). The
definition being provided in the compilation unit providing the main.
To me, this would have two benefits:

+ Easier to understand the linker messages when mixing object comming
from two different compilers.
+ Provided that the stab mechanism gives a good description of the
objects layout, there would be a better orthogonality between debugger
and compiler devlopments. This raises the question whether there has
been any effort made for standardizing the information contained in the
stabs specifically for C++. To be clear, I do not want a formalization
of the encoding (this would be great but is out of the scope here) but
of the minimum information that should be present for a debugger to be
used transparently (i.e. with no more a priori knowledge of the compiler
than it needs for a typical C compiler).

This would (in the long term at least and hopefully) allow an easy use
of vendor's debuggers with g++ (they often offer some goodies that are
not provided with gdb) and gdb for any vendor's compiler (it provides a
uniform interface for debugging across the many different platforms and
that's great). Of course, gdb, g++ can be replaced by any other products
(there are cited because they are free!!).

I'm aware of the fact that these problems preexists to C++, but I
believe that they are emphasized a lot with the current definition of
C++.

At this time, I suppose that nothing like this can be incorporated in
the draft standard, but I would be extremely interested in seeing your
comments.

--
Theodore Papadopoulo (papadop@sophia.inria.fr)
Projet Robotvis, INRIA, France
---
[ 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. ]