Il 03/06/19 23:04, Kevin Kofler ha scritto:
Giuseppe D'Angelo via Development wrote:Also, please name me 3 GUI frameworks that have not broken APIs for 30 years.Also also, please name me 3 libraries that have not broken APIs for the 30 years.There is at least one (almost): Win32 has now existed for 26 years without an ABI break. That said, it is painful to use (directly), proprietary, and not portable. But we have to admit that they did really well at maintaining compatibility.
Some API has been dropped by Win32 (first that comes in mind is NDDE). Still waiting for the other examples. (Anyhow, last time I checked, the development power behind Qt is a tiny fraction of the one available to Microsoft. I brought up the development bandwidth problem already.)
Also also also, at least in the x86-64 world, major "API breaks" at the assembly level have already somehow occurred. And that's an architecture that has been around for less than 20 years.Have they really? Software built for the first x86_64 CPUs still runs unchanged, doesn't it?
If you want your software to have security issues, yes. Otherwise you'll need to change your assembly. That's an API break in my book.
Qt has also become larger and larger over time (despite the removal of APIs considered obsolete).The removal of APIs in Qt 5 lifetime has been mostly "limited" to dropping entire obsolete modules. No cleanup has been done to deprecated API inside a module.I was comparing the size of Qt 3 and Qt 5. There have been 2 such cleanups between them: Qt 4.0 and Qt 5.0. Still, Qt 4 was much larger than Qt 3, and Qt 5 is much larger than Qt 4 was.Qt 6 wants to do that, and the point of this thread is how to minimize the pain.And my point is that the only way to minimize the pain is to just not do that to begin with. There needs to be a point where a library just stops doing new incompatible major releases. See how glibc has now been at glibc 2 (libc.so.6) for 22 years.
... Glibc has done countless API breaks:
https://raw.githubusercontent.com/bminor/glibc/master/NEWS
The intended _scriptable_ solution is 1) copy and paste Q_FOREACH from qglobal.h into a central header of your project 2) rename all occurrences it to MY_FOREACH 3) doneThat (telling the users to just copy&paste the code from the library) defeats the whole point of a software library.
Because Q_FOREACH does not belong to Qt. How about this: put it in a separate library, publish it to github, and port projects to use _that_ instead? It's still 100% scriptable.
This is just *false*. You're (deliberately?) ignoring the cost of memory allocations and deallocations, hiding them in big-O constants, something I already warned you about. I won't then waste time debunking this.If you have a list of 1000000 800-byte objects and you want to insert an element in the middle of the list, with a reasonable malloc implementation, the ONE allocation together with the 4 MB memmove for QList::insert will be negligible compared to the 400 MB (!) memmove for QVector::insert.
Third straw man in three emails. Inserting in the middle of a sequential container with a million elements is NOT a common use case. While at it, why don't you also measure the cost of iterating over the elements, as already suggested in an earlier email?
Of course, that doesn't imply that it is not possible to do better, in theory. But is this optimization [SSO] worth the trouble of breaking the ABI?Yes.And that's what I doubt, and you have not stated any arguments for your claim.
So you want me to dump here all the existing literature available around the benefits of SSO, for the sake of... what exactly? SSO is not an API break and therefore discussion about it does NOT belong to this thread.
Quite bored now, -- 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
