[C++-0x] User-defined literals.

[Jason Merrill]

On 09/17/2010 02:25 AM, Ed Smith-Rowland wrote:
> I am slowly working on user defined literals for C++-0x.

Thanks!  Please send future patches to gcc-patches and me directly.

Looking over your patch, I see you're doing a significant amount of it 
in the parser, which is incorrect; the draft says that a user-defined 
literal is a single preprocessing token, so

1.2QQ

(one token) is different from

1.2 QQ

(two tokens).

> Anyway, I managed to parse things like
>
>   long double
>   operator"" _foo(long double x) { return 2.0L * x; }
>
> The result is a normal function that I can either call like
>   operator "" _foo(1.2L);
> or just
>   _foo(1.2L);

You shouldn't be able to call it as just _foo(1.2L); an operator name is 
different from a normal function name.

> 1. A warning or error if a user chooses a suffix that gcc uses.  I was surprised that 'w', 'q', 'i', 'j' and several others were used by gcc for floats.  I won't be the only one.
> The standard is clear that implementations get first crack at these but it shouldn't be a mystery or a surprise when things don't work as expected.

> 2. Should we at least pedwarn about user not starting a suffix with an underscore?  Probably.  Non-underscore suffixen are reserved to the implementation 
but I think a user should be able to use one if it's not used by gcc 
though the user risks non-portability and potential but unlikely future 
breakage.

Can you point me to the relevant wording?  I'm not finding it.

> 3. The big one: Getting the integer(long long) and float(long double) suffixes that are not used by gcc out of the preprocessor.  Then we can build the calls.

Yep, I think we want a new CPP token type for user-defined literals that 
encapsulates both the raw literal and the suffix.

> 4.  If, for long long and long double the usual signature is not found, first look for a: _suffix(char*) and failing that: template<char...> _suffix().  So we'll need to make the lookup of these two signatures more complex.

Right, this will need a new overload resolution function.  2.14.5 tells 
you how it works; look at the overload set, see if it contains a 
particular signature, and build up a normal call as appropriate.

Jason