[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