Scott Hill wrote:
> 
> Mathias Broxvall <mbr### [at] swipnetseNOSPAM> wrote in article
> <1d8### [at] dialup122-3-36swipnetse>...
> >
> > extern "C" {
> >   ...
> >   /* All my great C prototypes here */
> >   ...
> > }
> 
> Yeah, that's the way to do it. I don't know how platform independent it is
> though, so you may run into problems and I've a feeling, even if it is part
> of the current C++ standard, it may well be dropped when the ANSI C++
> standard is finally released, sometime this year (hopefully),

Extern "C" is still in the standard. The necessity for linking with
other languages will always be there; there's no chance of it ever being
dropped.

> but,
> hopefully the name mangling problem will be cleared up as well.

No chance. The name mangling "problem" is there for a good reason. It's
not the result of an imperfect specification or lack of thought on
anyone's part; the C++ standard quite consciously and intentionally
*encourages* compiler writers to invent incomaptible name mangling
schemes.

The reason is that name mangling isn't the only difference between
compilers. The same class compiled by different compilers can differ in
many ways at the binary level -- different sizes for the primitive
types, different padding between elements, different choices for where
the vptr goes, how it's interpreted, or whether it's used at all. And so
on.

If name mangling incompatibility was "fixed", it wouldn't mean that
object modules compiled with different compilers could be used together.
It would just mean that the incompatibilities showed up as strange
behaviour and unpredictable crashes at run time, instead of (relatively)
clear error messages at link time. This would not be a Good Thing. So
compilers use incompatible name mangling on purpose.

So why didn't the standard fix this by specifying an interface at the
binary level (as Java did)? Because those different compiler conventions
are there for a reason. There is no one best way to build a class;
different binary standards are best for different purposes. Requiring
one binary interface would make the resulting code suboptimal in many
cases. (This is one of several reasons why Java can never match C++ for
efficiency no matter how good the compilers get. Lest I be accused of
language bashing, that doesn't make Java inferior -- it just has
different priorities.)

This problem isn't unique to C++, although many C++ bashers would like
you to think so. It's always been there in C too; what do you think all
those FAR/CDECL/STDCALL/PASCAL/WINAPI/etc prefixes (or the equivalent on
other platforms) are for? They're the equivalent of name mangling,
inserted manually by the programmer instead of automatically by the
compiler, to indicate different calling conventions.

-- 
Ross Smith ..................................... Wellington, New Zealand
<mailto:r-s### [at] ihugconz> ........ <http://crash.ihug.co.nz/~r-smith/>
   "Remember when we told you there was no future? Well, this is it."
                                                         -- Blank Reg

Post a reply to this message