This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[C++0x] User-Defined Literals
- From: Ed Smith-Rowland <3dw4rd at verizon dot net>
- To: gcc-patches at gcc dot gnu dot org
- Date: Mon, 11 Apr 2011 22:04:34 -0400
- Subject: [C++0x] User-Defined Literals
Greetings,
Here is a new patch for user-defined literals.
* New C preprocessor tokens are defined for numbers, chars, and strings
with suffixes are defined. They are lexed as complete tokens.
* The new tokens are passed through the C tokenized to the C++ tokenizer
and parser and so on.
* There is a new tree code and structure for user defined literals.
* Char type literals are completely finished.
* String type literals are completely finished including concatenation,
raw literals, etc.
* Numeric literals are *mostly* done (numeric argument operators and the
raw literal operator (const char *) forms are supported.
* LTO serialization seems to work. I'm storing the trees in my struct
rather than refs.
* All the checks (except noted below) for arguments are made.
* All the checks I could find concerning scope and linkage are made.
* Like before I issue a warning if the user-defined suffix for numeric
types is shadowed by our implementation
which includes not only the usual standard ones but several
extensions as well.
* You can't call the suffix as a function anymore (That was an error,
I'm mangling to __udlit<suffix> now).
There are some issues:
* Friend operators don't work. Literal operators can't be class members
but they could be friends.
* The template numeric literals don't work:
template<char...Char>
X operator"" QQQ();
- You *can* explicitly call the operator:
cout << operator"" QQQ<'A','B','C'>();
- The template parameters are *not* checked
- The void argument is *not* checked.
* Someday, we'll want to move Objective-C++ strings into the C++ string
lexer like it says in the notes.
I think we'll want to do some minimal surprise thing like *not*
allow @ strings to have suffixes.
I can't see a reason someone can't return an @ string from a
user-defined literal though.
I'm sure there are functional and aesthetic comments that people can make.
Have at it ;-)
Ed Smith-Rowland
Attachment:
patch_literal
Description: Text document