This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]