This is the mail archive of the
mailing list for the GCC project.
Re: ABI demangling problems
>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
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.