🚀 go-pugleaf

In article <4ks0c8$jte@piglet.cc.uic.edu> dhanle2@icarus.cc.uic.edu (David James Hanley) writes:

> : Correct about what?  That having a name-mangling standard for C++
> : would make C++ libraries easier to handle.  Sorry, but he's wrong,
> : and so are you.
> 
> 	Nope. You're the one who is wrong here.  But seeing as you
> replied to my first post about the matter with insults to me, I really
> doubt you are interested in serious exploration of the matter.  

I'd think twice before telling Andy flatly that he's wrong about some
basic C++ issue.  There might be a few people who know more about the
language than he does, but there sure aren't many.

And in this case, he does happen to be right.  There are a whole lot
of issues to be resolved if you want to link object files from two
compilers: sizes of basic types, direction of stack growth,
representation of the number of arguments passed to a subroutine,
order in which arguments are passed, mechanism for return types,
padding of data structures, mechanism for polymorphic function calls,
initialization of global data, layout of derived classes (especially
in the case of multiple and/or virtual inheritance), representation of
object type, mechanism for linking to dynamic shared libraries,
representation of exceptions, registering objects for destruction upon
stack unwinding, and many, many more.  These issues are the ones I
thought of off the top of my head, which means there are probably ten
times more issues that didn't happen to occur to me just now.

Object files from two compilers will never link together just by
accident: it only happens when one or more compiler vendors is
deliberately working for link compatibility.  Usually this is because
there's some implicitly (or explicitly) defined ABI, perhaps defined
by the vendor of the OS that the compilers are running on.

C ABIs exist for many (but not all!) popular platforms, including SGI
machines.  C++ ABIs necessarily deal with many more issues, so they're
still in the process of being developed.
-- 
Matt Austern
SGI: MTI Compilers Group
austern@isolde.mti.sgi.com