> On 23 Aug 2019, at 17:04, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Thursday, 22 August 2019 23:44:02 PDT Ville Voutilainen wrote: >>> This doesn’t solve the problem that you’re having when you want to use >>> anything outside the ascii range inside “literal”, as the encoding of the >>> source code on disk is not defined. u”…” or u8”…” defines the output >>> encoding (utf16 or utf8), but with the input encoding being undefined, >>> that is not helpful at all for writing portable code. >> Ack. Well, we can vote with our feet, and say that in Qt's realm the >> input encoding is expected to be utf-8. > > And we've done that and all of Qt's modules build like that.
Really? It’s probably what happens in practice in most cases on Linux and macOS, as their locale is utf-8, but we do not force the input encoding to anything as far as I can tell. There’s no -finput-charset=utf-8 anywhere in Qt’s sources. That implies that gcc will try to pick up the input charset from the locale. Cheers, Lars > > We just haven't forced that choice on our users. It's opt-in for them. > > But we can use u"" just fine, right now. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > _______________________________________________ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
