On Tue, 15 Nov 2022 08:52:24 +0000 Marc Mutz via Development <development@qt-project.org> wrote:
> There's nothing inherently Qt-ish about owning containers. Yes and no, because owning containers are part of the very "Qt-ish" Implicit Sharing idiom, which one is _great_ for the ease of use, safety and optimization it provides. ~115 Qt classes: https://doc.qt.io/qt-6/implicit-sharing.html >QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String, > can be used to to make UTF-8 a first-class citizen in Qt. Maybe, but I see a deviation from simplicity (not "Qt-ish") >But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many >deep copies it takes to convert to and from UTF-16 from native >encodings, people still worship it as god-given. It's not. If this is "sacrosanct", this is simply because many people appreciate QString for its rich API and ease of use. This has to be respected. Philippe > On 15.11.22 08:14, Ulf Hermann via Development wrote: > >>> So, if the method immediately converts whatever it gets to QList or > >>> QString, then there is no point in passing it a span or view. > >> > >> My point is that there _is_. Citing my blog post: > >> > >> callConsumeQStringHelloWorld(): > > > [...] > > > > That's the worst case scenario of passing an 8bit string literal to a > > function that takes a QString. We have QStringLiteral to avoid the 8bit > > to 16bit conversion, but I know there are more problems with that. > > > > Now lets look at the case of passing a pre-existing QString (i.e. one we > > don't have to create in place) to a function taking QAnyStringView and > > storing the result as QString. > > > > // somewhere: > > QString a; > > void setter(QAnyStringView view) { a = view.toString(); } > > > > // elsewhere: > > QString foo; > > [ ... modify foo ... ] > > setter(QAnyStringView(foo)); > > > > That's a deep copy. A deep copy of a string is obviously more expensive > > than the overhead of calling the QString ctor and dtor. > > That remains to be proven. A rule of thumb for atomics is that they're > two orders of magnitude slower than a normal int. They also still act as > optimizer firewalls. With that rule of thumb, copying 50 char16_t's is > faster than one ref-count update. What really is the deciding point is > whether or not there's a memory allocation involved. I mentioned that > for many use-cases, therefore, a non-CoW SBO container is preferable over a > CoW > non-SBO one. > > If QString and QByteArray had both efficient substringing and SBO, my > arguments would carry much less weight. But we have neither, and adding > it (esp. SBO) to QString for Qt 7 will break users, silently. Therefore > it's prudent _not_ to change QString, but to add QSmallString or > something instead. Until then, u16string and QVLA<char16_t> can be used, > by users and implementations. > > Any way you turn it, non-owning containers in the API make for long-term > stable APIs even as we improve our container classes in incompatible ways. > > > Which case is > > more common? And by what factor? > > > > I can't say what case is more common. What I can say is that the risk of > > creating deep copies sounds worse to me than the risk of calling the > > QString ctor and dtor too often. > > > > This is what I mean with "fuzzy". We don't really have the data to > > support a move to QAnyStringView for all of our API. > > I can say with firm belief that, _atm_, passing QString is more common. > But this is a self-fulfilling fact. The tst_qsettings experiment shows > what can happen if you port an API that doesn't naturally receive > pre-made QStrings. > > If you want to take a peek at a world without owning containers, use the > Qt 6 QXmlStreamParser API or llvm. > > With the caveat that the problem with QXmlStreamParser is that it needs > to convert to UTF-16. The vast majority of XML data is _not_ in UTF-16. > If QXmlStreamReader's API was formulated in QAnyStringView, it wouldn't > have to. We could just mmap() files and hand out QAnyStringViews to > tokens. Not going into whattaboutism here, but what about all those > unnecessary encoding conversions? Each one is a deep copy, too. UTF-16 > is a total alien in the Unix world, and, connecting to your world, I > think it's safe to assume that very few QML files are encoded in UTF-16, > either. And PySide string are also not encoded in UTF-16, I think. > > But UTF-16 is sacrosanct in Qt. It's a cult. Irregardless of how many > deep copies it takes to convert to and from UTF-16 from native > encodings, people still worship it as god-given. It's not. > > No-one would use Clang if it internally converted everything to UTF-16 > first. It would be too slow. > > QAnyStringView, QUtf8StringView and, later, QAnyString, QUtf8String, can > be used to to make UTF-8 a first-class citizen in Qt. > > Likewise, owning containers are also sacrosanct in Qt. They're a cult. > Irregardless of how many deep copies it takes just to call a Qt function > from Python, Java/Script or QML, people still > worship them as god-given. They're not. > > There's nothing inherently Qt-ish about owning containers. Qt is all > about allowing developers to write great applications across platforms. > Ideally, we'd focus on picking up developers where they come from. That > means instead of inflicting a Java-ish C++ API on Python programmers, we > make PySide rock by minimizing copies between Python and Qt/C++ data > structures. iow: NOI. > > Guys, take the blinkers off :) > > Thanks, > Marc > > -- > Marc Mutz <marc.m...@qt.io> > Principal Software Engineer > > The Qt Company > Erich-Thilo-Str. 10 12489 > Berlin, Germany > www.qt.io > > Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen > Sitz der Gesellschaft: Berlin, > Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > _______________________________________________ > 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