On 18/03/2019 17:02, Matthew Woehlke wrote:
On 16/03/2019 12.13, Giuseppe D'Angelo via Development wrote:
What I meant is this: during phase 5 and 6, are string literals
simply sequences of symbols from a set, or are they already encoded
in some encoding? From my reading, it's the former (the ex
On 16/03/2019 12.13, Giuseppe D'Angelo via Development wrote:
> What I meant is this: during phase 5 and 6, are string literals
> simply sequences of symbols from a set, or are they already encoded
> in some encoding? From my reading, it's the former (the execution
> character set is just this --
Hi,
Il 15/03/19 19:09, Matthew Woehlke ha scritto:
The mapping of \u escape sequences to the execution character set
happens before string literal concatenation (translation phases 5/6).
But AFAIU the mapping is purely symbolic, and has nothing to do with any
actual encoding, so MSVC is at fault
On Friday, 15 March 2019 11:12:30 PDT Thiago Macieira wrote:
> On Friday, 15 March 2019 11:09:20 PDT Matthew Woehlke wrote:
> > (Note: Another solution is to redefine QT_UNICODE_LITERAL_II to `u ##
> > str`, but that's SIC.)
>
> And doesn't help, because you *can* write
>
> QStringLiteral("
On Friday, 15 March 2019 11:09:20 PDT Matthew Woehlke wrote:
> (Note: Another solution is to redefine QT_UNICODE_LITERAL_II to `u ##
> str`, but that's SIC.)
And doesn't help, because you *can* write
QStringLiteral("a" "b" "c")
--
Thiago Macieira - thiago.macieira (AT) intel.com
Softw
On 15/03/2019 08.27, Giuseppe D'Angelo via Development wrote:
> Il 14/03/19 22:48, Thiago Macieira ha scritto:
>> For
>>
>> char16_t text1[] = u"" "\u0102";
>>
>> It produces, without /utf-8 (seehttps://msvc.godbolt.org/z/EvtKzq):
>>
>> ?text1@@3PA_SA DB '?', 00H, 00H, 00H ; t
On Friday, 15 March 2019 05:27:09 PDT Giuseppe D'Angelo via Development wrote:
> The mapping of \u escape sequences to the execution character set
> happens before string literal concatenation (translation phases 5/6).
> But AFAIU the mapping is purely symbolic, and has nothing to do with any
> act
Il 14/03/19 22:48, Thiago Macieira ha scritto:
For
char16_t text1[] = u"" "\u0102";
It produces, without /utf-8 (seehttps://msvc.godbolt.org/z/EvtKzq):
?text1@@3PA_SA DB '?', 00H, 00H, 00H; text1
And with /utf-8:
?text1@@3PA_SA DB 0c4H, 00H, 01aH, ' ', 00H, 00H
On Thursday, 14 March 2019 13:54:29 PDT NIkolai Marchenko wrote:
> I've posted about this issue (I think) on slack a bit earlier, see
> https://cpplang.slack.com/archives/C29936TQC/p154989901601
For those who can't read it, the suggestion was to use the /utf-8 option to
the compiler (with qma
I've posted about this issue (I think) on slack a bit earlier, see
https://cpplang.slack.com/archives/C29936TQC/p154989901601
On Thu, Mar 14, 2019 at 11:51 PM Matthew Woehlke
wrote:
> While working on some modernization of my application — in particular,
> converting some UTF-8 literals to u
On 14/03/2019 16.50, Matthew Woehlke wrote:
> While working on some modernization of my application — in particular,
> converting some UTF-8 literals to use QStringLiteral — I noticed a
> concerning compiler warning:
>
> warning C4566: character represented by universal-character-name
> '\uXXX
While working on some modernization of my application — in particular,
converting some UTF-8 literals to use QStringLiteral — I noticed a
concerning compiler warning:
warning C4566: character represented by universal-character-name
'\u' cannot be represented in the current code page (1252)
12 matches
Mail list logo