ABI demangling problems

[Eljay Love-Jensen]

Hi Asfand,

 >I wish there was a standard C++ way of doing demangling in the official 
standard (C++0x perhaps?).

Depending on your viewpoint, either unfortunately (or fortunately), the 
official standard C++ does not address C++ ABI.

My viewpoint is that it is "unfortunately".

I presume the ISO/IEC C++ WG either thinks it is "fortunately", or that 
standardizing the C++ ABI is a can-of-worms that they didn't want to 
tackle.  (I believe the various C++ compiler vendors had a strong influence 
in the decision to let the C++ ABI be someone elses problem, and not part 
of the C++ ISO 14882 standard.)

That said, there appears to be a C++ compiler vendor-level initiative of 
sorts to (de facto) standardize the C++ ABI.  That's as "grassroots" as can 
be, in this situation.  Don't hold your breath to await compliance from all 
your favorite C++ compiler vendors!

What would C++ ABI standardization compliance provide?  All C++ names 
mangled the same way.  Exception handling handled the same way.  RTTI 
handled the same way (including POD types).  All stacks (on a given 
architecture/OS) structured the same way.  All calling conventions the 
same.  All C++ infrastructure the same (such as initializations of 
statics), handled the same way.  Anonymous namespaces would probably be 
handled the same way (and not pollute the TOC with random munged names 
different from compile-to-compile!).  Instantiated templates would be 
compiler agnostic.  Different pre-built binary libraries (.a, .so, .shlib, 
.library, .dll, .lib, whatever) would be compiler agnostic.  All intrusive 
(in the shared header files) extensions would be strongly discouraged by 
the developer community at large.  And that's probably just the tip of the 
iceberg.

I have not been following the progress of the vendor-level initiative C++ 
ABI de facto standard.  I don't expect it to be completed and implemented 
within my lifetime.

Sincerely,
--Eljay