New demangler in C++

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| > | I think it's a mistake to do a new implementation in C++.
| 
| > I beg to differ.
| 
| > | I think that the demangler should be written in C as an independent
| > | module so that it can be used in programs that are not written in
| C++.
| > | And I think that having two demanglers just makes things worse; now
| > | they can be out of synch in all sorts of weird ways.
| 
| > While I recognize of the out-of-sync danger of having two independent
| > implementations, it is a mistake to force a C implementation of the
| > demangler on every body.  This message is not a religious matter.
| 
| I guess what I think is this:
| 
| - The demangler ought to be able to be linked into GDB, binutils, source
|   browsers, etc.
| 
| - Those applications presently use no C++.
| 
| I think that the maintainers could possibly be persuaded to link in one
| C++ .o file -- but probably not libstdc++.

Some software like Mesa3d have components written in C++ but manages
to be linkable to a C program using only a C compiler by pre-linking the
C++ runtime library (including the "STL" part) into the final libGLU
library.  I believe we can use such approach for the demangler.

| So, if the file were written in C++ -- but didn't use <string> -- I'd
| probably resist less.  You're right that if it's written in C++, but
| doesn't use C++ library stuff, that it could present a C interface and
| that would be fine.

I would like we investigate ways to present a C interface to the
demangler (if written in C++), using the linkage-specification mechanism
('extern "C"') offered by the C++.

| The key point is that I think it's a big mistake to have two
| demanglers.  If we're going to write a new one, we should make sure that
| it can replace the old one, not just get added to the mix.

This is OK fine by me.

Benjamin?

-- Gaby