🚀 go-pugleaf

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

> 	No, actually, when I was trimming the post, I accidentally 
> clipped off your name, and made a typo when I typed it back in.  
> I realize that mistyping your name is a mortal sin to the god of c++,
> even if he projects his like for flaming strangers onto others.

If you had retracted your (claimed) inadvertent insult,
I would have believed you.

> : 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.  But
> hurling childish insults.

That's two mistakes.  The first one is believing that a name-mangling
standard for C++ would solve any problems, the other is in believing
that I am trying to insult you.

> : Name mangling, that is, the conventions that a compiler uses
> : in translating names from the source program into names
> : that the linker sees, is only one of a large number of things
> : that must be agreed before programs compiled with one compiler
> : can be linked with programs compiled with another.

> 	Sure.  No one is saying anything different.  Name mangling
> if only one of the obstacles to be overcome.  But many of these other
> obstacles have been overcome on other platforms already.  It appears to
> be somewhat stupid to make yet more obstacles by failing to standardize
> something as simple as name mangling.

I completely agree that it seems stupid.  It is only on closer observation
that the fundamental difficulty of doing so becomes apparent.

In order for a standard to have any meaning at all, that standard has
to specify the behavior of something.  Moreover, any standard has to
do so in a way that makes it possible to determine whether that 
something meets the requirements of the standard or not.

Now, suppose a name-mangling standard existed.  What would it
specify the behavior of?  Linkers?  What is a linker?  What if I
give you a C++ implementation that has no linker at all?  Would you
claim that such an implementation cannot be standard conforming
because it does not have mangled names for you to inspect?  There
is no such requirement on C implementations; why should there be
such a requirement on C++ implementations?

Or what if I write a linker that does not use name mangling at
all, but instead stores types in its symbol table?  Would you
reject such a linker because it does not mangle names properly?

Of, for a third example, consider a compiler and linker that does
follow the hypothetical name-mangling standard, but gives its users
no way of determining what names it actually uses?  Does such a
compiler/linker pair conform?  How can you tell?  How can you test
conformance?

These are all questions that you must answer before you can even think
about what a name-mangling standard might mean.

> :  If some
> : of those things are made compatible and not others, that can
> : easily make the problems worse instead of better.

> 	How can it be worse than not working at all?  

Easy: it could work some times and not others.  That is the situation
with some of my incompatible C compilers today: they work fine with
lots of programs but crash with some.

> :  The reason
> : is that programs may appear to work compatibly when in fact
> : they are working only by accident.

> 	Remind me to throw away all of my C programs in that case--they
> a are all linked with a library compiled on a different compiler, 
> and are therefore broken.  Pity.

OK, consider yourself reminded.

> : Well, good for you.  That still does not gainsay the fact that
> : handing the same names to the linker does not make compilers
> : compatible.

> 	No, and again, no one said it did.  But a lot of work has been
> done to allow link-compatibility within C libraries.  It seems foolish
> to throw this all away.

Indeed.  But having a name-mangling standard would not affect this.

> : > : Getting a single binary library to work with both those
> : > : C compilers is no easier than it is in C++.

> : > 	Wrong.  As evidence, we do this all the time in C,
> : > but I've never seen it done in C++. 

> : I completely agree with you that link compatibility between C++
> : compilers is more difficult to achieve, hence less common, than
> : link compatibility between C compilers.

> 	Whups!  A few lines above you said it was no easier!

Did I?  Where?

> : But agreeing on a standard for name mangling would not solve that
> : problem, because it is vanishingly rare that two C++ compilers are
> : binary compatible in all details except for names.

> 	Right.  Since the name mangling is unspecified, why stick to the
> standard techniques for the platform?  We can squeeze out another 5% of
> performance by passing the first paramater as a register( or whatever ).
> Binary incompatibility between compilers is a serious problem, for sharing
> of libraries, and other such activities, and it sure would help things
> if the committee could have put it in the standard, removing yet one
> more problem.  I mean, they added literal "and" and "or" for bob's sake.

Putting name mangling into the standard -- if anyone could figure out
how to do it meaningfully -- would not remove any problems.  If two compiler
vendors want to be compatible with each other, they will do so, with or
without a name-mangling standard.  If they want to be incompatible with
each other, they will also do so.

By the way, why aren't you agitating for a name-mangling standard in C?
Name mangling is a potential problem there too.
-- 
				--Andrew Koenig
				  ark@research.att.com