[cfe-dev] Almost there...

AlisdairM(public) public at alisdairm.net
Sat Jun 6 03:11:02 PDT 2009


> -----Original Message-----
> From: Cédric Venet [mailto:cedric.venet at laposte.net]
> Sent: 05 June 2009 19:07
> To: AlisdairM(public)
> Cc: cfe-dev at cs.uiuc.edu
> Subject: Re: [cfe-dev] Almost there...
> 
> I implemented raw string a long time ago, but never got to clean it up
> enough to commit. see:
> 
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-June/002054.html
> 
> and the following mails. (the latest patch should be attached to
> http://lists.cs.uiuc.edu/pipermail/cfe-dev/2008-June/002085.html)
> 
> There is probably some bit rot but the lexer didn't change that much,
> so it may be a good starting point (at least there is some comment from
> chris and eli). I also attached two small test cases.

Thanks - that looks really helpful as a starting point.

I'm thinking about char16_t/char32_t and the inevitable string concatenation
as I do this, so might be a little longer than I thought.  Not sure whether
it makes sense to tackle character types first of raw literals - although I
definitely think they should be incrementally supplied as two distinct
tasks!

Reason I am thinking about this now is what does a d-char mean for a
char32_t string?  Assuming we can read a UTF32 formatted source file, those
UTF32 glyphs used to denote the delimiter will be transcoded down to
universal-character-names in the basic source character set, taking up to 10
characters each.  That means potentially a single character delimiter from
the users' perspective.

Hmmm, that seems to be what is required today so that is what I'll
implement, although I'll probably file an issue with wg21 to see if this is
really what is intended.

AlisdairM







More information about the cfe-dev mailing list