[Development] Oslo, we have a problem</apollo 13> [char8_t]
abbapoh at gmail.com
Mon Jul 8 21:15:35 CEST 2019
No, what I’ve actually meant - is it possible to have a free function that takes some string view (QLatin1StringView?) and operates on that view instead of allocating a new string. I’m asking because I’m kinda nooby in UTF and I don’t really know what should happen for non-ascii characters in that case (should such a function just ignore them?).
Such a function can solve the problem with .toUpper()/toLower() in QByteArray - just remove them and use free function if you’re sure your string is latin1/you don’t care about UTF (which is the currently supported case).
On the other hand, if we introduce QLatin1String/QUtf8String/Q(Utf16)String, such a function will probably won’t make much sense (except for optimization purposes/being an implementation detail) since the API for those classes should be the same, i.e. have some allocating toUpper/toLower methods (since string size can change after those operations).
> 8 июля 2019 г., в 8:49, Giuseppe D'Angelo via Development <development at qt-project.org> написал(а):
> Il 08/07/19 07:54, Иван Комиссаров ha scritto:
>> Is it possible to do an inplace toUpper() for the ASCII encoding?
> At some past QtCS it was deemed that we should add foo() functions to complement any toFoo() -- the former would act in-place, the latter would return a new value.
> But I don't think any of that has happened yet, so your best shot is hoping that foo() is overloaded for rvalue *this. toUpper() is, hence the in-place modifying version is the
>> ba = std::move(ba).toUpper();
> which IMNSHO is quite *bad* to read.
> My 2 c,
> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
> Development mailing list
> Development at qt-project.org
More information about the Development