[cxx-abi-dev] Proposed ABI changes for new C++0x SFINAE rules

John McCall rjmccall at apple.com
Wed Jul 14 17:01:16 UTC 2010


On Jul 14, 2010, at 7:56 AM, David Vandevoorde wrote:

> 
> On Jul 13, 2010, at 10:08 PM, John McCall wrote:
> 
>> On Jun 30, 2010, at 8:33 AM, David Vandevoorde wrote:
>>> - We propose additional encodings for literals that can now appear in signatures.  nullptr is "LDn0E"; i.e., "a zero of type std::nullptr_t".  More interestingly, string literals are encoded as L<character type>E, where <character type> is the encoding of the (unqualified) underlying character type.  This has a few consequences for the demangler: It cannot actually reproduce the string, and it can only distinguish character literals from string literals after having seen the first character following the character type code.
>> 
>> Is this sufficient?  Overloading can be dependent on the length of the string, i.e. these are different templates:
>> template <class T> auto foo(T x) -> decltype(bar(x, "abc"));
>> template <class T> auto foo(T x) -> decltype(bar(x, "abcd"));
> 
> Good catch!
> 
> How about using:
> 
> 	L <string type> E
> 
> ?
> 
> That matches the (new) nullptr approach.  In addition to the string size, it also encodes the cv-qualifier, which ensures that we get distinct encodings for compilations with a mode where string literals are non-const.

That seems reasonable to me, and has the advantage of not colliding with character literals.

I'm a little worried about giving literals different manglings in different translation units, but only a little, since it already affects overloading.  I feel like I can adequately explain to a user why their program doesn't link and what they can do about it.

John.


More information about the cxx-abi-dev mailing list