Fw: [cxx-abi-dev] Decimal Floating Point mangling was(Fw: [cxx-abi-dev] C++0x: Mangling of rvalue reference type)s

[Dennis Handly]

>From: Michael Wong <michaelw at ca.ibm.com>
>I believe one of the point of an ABI is to settle on one type where there 
>are ambiguity or possible differences in choices. Otherwise, it is not an 
>ABI and there would be no interoperability.

Exactly.

>So I agree with Dennis that having both types would be confusing.
Michael Wong

Unless you allow a platform to pick one.

>From: Sean Perry <perry at ca.ibm.com>
>Are you trying to say that the C++ class type shall be binary compatible
>with the C native type?  That is going to fail immediately on parameter
>passing and return values.

Why?  We just wave our ABI wands and say it can't.

>then someone can throw a C
>native type and catch it as the C++ class type.  Similar odd behaviour
>would happen with dynamic casting.  The fact is that we have two different
>types because C++ choose to implement decimal floating point as a class.
>We need two different mangling schemes.
Sean Perry

Can't we make sure we mangle them the same and so the type_info would
be the same?

>From: Michael Wong <michaelw at ca.ibm.com>
>Absolutely not. That would be silly even to me.

As Prem asks below, are you saying:
  Are you trying to say that the C++ class type shall be binary compatible
  with the C native type?

We want it to be the same.

>The point is that for platforms that support native types, the native type
>mangling is available for a potentially more efficient implementation. For
>platforms that can only support emulation, the class library type and its
>mangling is available. Have I missed the point?
Michael Wong

The only point you missed is it not only to do with platforms but the
compiler too.

>From: Daveed Vandevoorde <daveed at edg.com>
>Most likely, indeed (though magical class types could be possible).

Sign me up for magic.  ;-)

>I still don't see why.  C signatures need no mangling.  In C++ it's a  
>class type, so there is an encoding for that.
	Daveed

Except my suggestion is that we special case that class type and mangle
it as the native type.

>From: PremAnand M Rao <premanand.rao at hp.com>
>I am not sure what you said "Absolutely not" to.

Right.

>If the mangling for the type are different based on how they are
>implemented, it removes a lot of flexibility from this choice.
PremAnand.

Right.