Big annoyance in TR1

[Mirco Wahab]

Best wishes for 2008!

After studying the fine print
for the "Next Big Thing (tm)"
I *still* found no word about
one big issue, the "raw string"
or "verbatim string" etc.

Whats so complicated with this
little detail? After working
a while with the Boost::Regex
(which goes into TR1), I have
to say - it's like to repaper a
room through the keyhole in it's
door - i end up writing and testing
the regular expression in Perl and
converting the result then by doubling
it's length by added backslashes - to
C++ strings.

Maybe somebody can enlighten me
whats wrong with raw strings
(as every other single language
of some importance nowadays has
them).

What about

char stuff[] = R' this is verbatim (\s* \w+ \s* $)';
Thanks and regards

Mirco

[James Kanze]

On Dec 31 2007, 5:55 pm, Mirco Wahab <[e-mail]:

After studying the fine print
for the "Next Big Thing (tm)"
I *still* found no word about
one big issue, the "raw string"
or "verbatim string" etc.

Whats so complicated with this
little detail? After working
a while with the Boost::Regex
(which goes into TR1), I have
to say - it's like to repaper a
room through the keyhole in it's
door - i end up writing and testing
the regular expression in Perl and
converting the result then by doubling
it's length by added backslashes - to
C++ strings.

The TR was purely library, and didn't consider any changes to
the basic language. The current draft has nothing less than 10
different types of string literal, including 5 for raw strings.
Basically (if I've understood correctly):

escapes
prefix recognized type encoding

<nothing yes char impl. def.
u8 yes char UTF-8
u yes char16_t UTF-16
U yes char32_t UTF-32
L yes wchar_t impl. def.
R no char impl. def.
u8R no char UTF-8
uR no char16_t UTF-16
UR no char32_t UTF-32
LR no wchar_t impl. def.

This was only really integrated into the draft in the last year
or so, so probably isn't yet implemented in very many, if any
compilers. (In an ideal world, only the u8 and U variants would
be used. But history can't be ignored.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]