Oct 4, 2010 11:26:15 AM, ja...@redhat.com wrote:
>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).
Right. I've resigned myself to having to scan for these as a single token.
That (and Real Life) is what is slowing me down.
I think I may have to create new tree types for these literals.
>> 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.
According to 13.5.8/7 :
[ Note: literal operators and literal operator templates are usually invoked
implicitly through user-defined
literals (2.14.8). However, except for the constraints described above, they
are ordinary namespace-scope
functions and function templates. In particular, they are looked up like
ordinary functions and function tem-
plates and they follow the same overload resolution rules. Also, they can be
declared inline or constexpr,
they may have internal or external linkage, they can be called explicitly,
their addresses can be taken, etc.
— end note ]
>> 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.
I *always* have trouble finding this ;-)
17.6.3.3.5 User-defined literal suffixes
[usrlit.suffix]
Literal suffix identifiers that do not start with an underscore are reserved for
future standardization.
>> 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 _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
>
Thanks for looking this over.
Ed
