On Friday, 15 May 2020 03:33:28 PDT Lars Knoll wrote: > Pretty much all uses of QL1String that I’ve seen are about ASCII only > content. That is certainly true for Qt itself, but also to a large degree > for our users. For those, utf-8 conversions are within 5% of latin1 > decoding. This makes it very clear to me that we should *not* have any > special handling for ascii that require a separate API.
We don't want Latin1 content in our files. There are two reasons for having QLatin1String and not QAsciiString: 1) historical. It was added in 4.0 (2005) ,when a good fraction of people were still running 8-bit Latin1 or Latin9 as their locales. It was actually added as a replacemente for people writing macros like this in 3.x times: #define L1S(x) QString::fromLatin1(x) Additionially, we mis-purposed the name "Ascii" in Qt to mean "locale-encoded strings". 2) the Latin1 codec is FAST, but only because it needs to do no error checking. If we had a QAsciiString class or proper US-ASCII conversion functions, we'd get bug reports that something with a high bit set was not flagged and replaced with U+FFFD Replacement Character when converted. This error checking is similar to the UTF-8 decoding, which would make it as fast as the UTF-8 decoder in terms of performance for US-ASCII content. -- 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
