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