The most recent publicly available C++0x draft (N2914) says this about
user-defined-string-literals:

> If L is a user-defined-string-literal, let str be the literal without its ud-suffix and let len be the number of characters (or code points) in str (i.e., its length excluding the terminating null character). The literal L is treated as a call of the form operator "" X (str , len )

with no option to use a literal operator template, as one can do with
all other literal types. So I cannot write, for example:

    template <char... s>
    regex operator "" rx () {
      ...
    }

that would somehow "compile" regular expressions at compile-time, and
have it work for string literals. My only option is to take the raw
argument either as "const char*, or as "const char (&)[N]" for
template<int N>, but those preclude any sort of compile-time trickery,
either TMP or constexpr.

What is the rationale for this restriction? Why are operator templates
supported for all numeric literals, but not for strings?


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

On 15 Aug., 21:37, Pavel Minaev <int...@gmail.com> wrote:
> The most recent publicly available C++0x draft (N2914) says this about
> user-defined-string-literals:
>
> > If L is a user-defined-string-literal, let str be the literal without its ud-suffix and let len be the number of characters (or code points) in str (i.e., its length excluding the terminating null character). The literal L is treated as a call of the form operator "" X (str , len )
>
> with no option to use a literal operator template, as one can do with
> all other literal types. So I cannot write, for example:
>
>     template <char... s>
>     regex operator "" rx () {
>       ...
>     }
>
> that would somehow "compile" regular expressions at compile-time, and
> have it work for string literals.
>
> What is the rationale for this restriction? Why are operator templates
> supported for all numeric literals, but not for strings?
>
As far as i know, the rationale is that it's too difficult to
implement it on some implementations, because of how string literals
are concatenated.

However, i wonder, if that's the sole reason, what about using
character literals? They seem to not support the template version too,
but i wonder whether this could be allowed and is feasible:

'[0-9]+'rx

It could call your literal operator template.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

"litb" <Schaub-Johannes@web.de> wrote in message
news:0e47764c-35b0-4059-91ee-ab12dd41c9b1@n11g2000yqb.googlegroups.com...
> On 15 Aug., 21:37, Pavel Minaev <int...@gmail.com> wrote:
>> The most recent publicly available C++0x draft (N2914) says this about
>> user-defined-string-literals:
>>
>> > If L is a user-defined-string-literal, let str be the literal without
>> > its ud-suffix and let len be the number of characters (or code points)
>> > in str (i.e., its length excluding the terminating null character). The
>> > literal L is treated as a call of the form operator "" X (str , len )
>>
>> with no option to use a literal operator template, as one can do with
>> all other literal types. So I cannot write, for example:
>>
>>     template <char... s>
>>     regex operator "" rx () {
>>       ...
>>     }
>>
>> that would somehow "compile" regular expressions at compile-time, and
>> have it work for string literals.
>>
>> What is the rationale for this restriction? Why are operator templates
>> supported for all numeric literals, but not for strings?
>>
> As far as i know, the rationale is that it's too difficult to
> implement it on some implementations, because of how string literals
> are concatenated.

I think such issues only exist if the template recives uncooked string
literals (broken up by character). But in my opinion, that would be
undesireable anyway. See the raw sting literal example below for the
reasoning. Obviously the implementation will eventually determine the
character sequence contained in any string literal, and that is all that is
really needed.


Epecially note the issues with passing a template an uncooked form of a
string like
r"TeX[\foo]TeX"suffix.

That would become something like:
operator ""
suffix<'r','"','T','e','X','[','\\','f','o','o',']','T','e','X','"'>().
That of course is absurdly difficult to parse or otherwise use.

It might be better is we passed a cooked form seperated by character,
without the trailing NULL, since that would be redundant.
Then the above would be:
operator "" suffix<'\\','f','o','o'>()
which is far more manageable.

There are some downsides, such as not being able to interepet escape
sequences in regular strings in a special way, although the fact of the
matter is that since we don't have any support for uncooked string literals
anyway, so the templated form could still do everything that can currently
be done anyway.


--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]