Il 03/06/19 00:08, Kevin Kofler ha scritto:
Ballast (obsolete functionality, for various degree of "obsolete") has to be dropped from time to time, causing API breaks. The question in this thread is how to manage those API breaks to be as painless as possible.What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there.
Rightfully? By what right exactly?
I'd rather get fewer (or even no) new features than losing existing ones.
How is this even an argument? Qt will need to evolve and acquire features to remain competitive. Again, development bandwidth is finite: either the overall quality decreases or some things have to get dropped.
See also Boudewijn Rempt's blog post on the subject: https://valdyas.org/fading/hacking/happy-porting/
I agree with the principle (API breaks are painful), but I strongly disagree with the idea that no API breaks can ever possibly happen. And the specific example is a terrible one to make a point as the resulting API break is trivial to work around (I defined such breakages "scriptable").
Changes such as deprecating or incompatibly rewriting a data structure as central as QList (as seems to be already consensus for Qt 6) are just a major disservice to developers.... exactly, because it's an API break. How can we minimize the damage?By simply not doing this change, not now, not ever. An array of pointers is the most efficient data structure in practice (operations are at most O(n)), dropping it in favor of an O(mn) data structure (where m = sizeof(T)) such as QVector is a pessimization. And QList also has the prepend optimization that makes most prepends even O(1) rather than O(n). I don't see why almost everybody hates it.
As written, the above makes no sense, as it looks like you're comparing apples and oranges: time complexities against space complexities.
The fact is: once one removes the big-O factors and deals with actual numbers and real world hardware, QVector becomes much better than QList as a _general purpose_ sequential container. Emphasis on the general purpose, please.
Hence, we want Qt to move away from QList (and encourage users to do the same). The point of this thread, once more, was asking how to do that as painlessly as possible.
ABI breaks such as the QString SSO (that also seems to be already consensus for Qt 6) are also unnecessary and probably also counterproductive in some use cases.What? Why?For the "unnecessary" part, because Qt has been working fine without QStringSSO for years.
Nice try: https://en.wikipedia.org/wiki/Appeal_to_tradition
Whether it is actually a performance win or not is irrelevant because code manipulating QString is almost never performance-critical. (The bottleneck is typically the user.)
"Almost never" is simply wrong (or: [citation needed]).First and foremost, it's wrong because containers and core classes in general are the ones MORE likely to be used in performance critical scenarios.
Second, string classes in all major C++ libraries and frameworks are deploying SSO *because* it is a performance win.
Third, in a library, *every codepath* is a bottleneck for some user, so the library must to be as efficient as possible everywhere.
For the "probably also counterproductive" part: * Because there are surely architectures or environments where copying 256bytes (or whatever the SSO max length actually is)
This is a straw man argument, specifically an exaggeration.At some QtCS Thiago was talking about 23-24 QChars, i.e. 48 bytes, plus a couple of pointers or so, to bring it to 64 bytes (~ a cacheline).
* Because the total memory use for an array of QString will likely be higher, due to the padding (space reserved for SSO)?
... or much, much, much lower because you don't have to allocate every string's payload separately.
QString with SSO will make Qt5List<QString> work in array-of-pointers mode, instead of pure vector mode, yes. But the decision of moving away from QList had very little to do with this particular point. And we already had our share of this: QList<QImage>, QList<QSharedPointer>, QList<QVariant>, and so on, see the other email.* Because it means a QString will no longer fit in a pointer slot, which breaks the QList optimization and is the main reason why people want to get rid of QList as we know it now?
***ANYHOW***:This thread was about managing API breaks. Adding SSO to QString is not meant to be an API break (*). Please stop derailing the thread.
(*) Emphasis on _meant_, because obviously it yields observable side effects.
Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@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
smime.p7s
Description: Firma crittografica S/MIME
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
