string constant mangling

[David Vandevoorde]

On Mar 8, 2011, at 11:43 AM, Jason Merrill wrote:

> On 07/14/2010 10: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.
> 
> It occurs to me that now with constexpr, string constants can appear in a constant expression:
> 
> template <typename T> constexpr T f(const T* p) { return p[0]; }
> template<int> struct N { };
> template <typename T> N<f((const T*)"1")> g(T);
> template <typename T> N<f((const T*)"2")> g(T);
> 
> Here the two 'g's are different templates.

Ouch :-(  I guess another tweak is needed then.

	Daveed