Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 18:46:31 PDT Konstantin Tokarev wrote: > This can be done with qmake if we implement ord I want to do a bit more in the shell script. All steps optional: First, I want to pass the XML source through xml sel -D -B -t -c / That will minify the source. That reduces the uncompressed size by about 10%. Second, I'm also thinking of compressing with gzip or zstd. The problem with that is that the tool may be present in the system but not the headers, which would cause decompression to fail. So I'm not sure this is a good idea. Of course, on Windows/MSVC you'd get neither minification nor compression. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
03.06.2019, 21:01, "Thiago Macieira" : > On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote: >> 03.06.2019, 09:06, "Thiago Macieira" : >> > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >> >> I also managed to get that done with a <10 lines of "plain cmake": >> >> >> >> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0 >> >> cb05 7/src/CMakeLists.txt#L46-L54 >> > >> > Yup, I figured with CMake it would be possible. But I'm trying to get this >> > in Qt 5 first. >> >> Does qmake miss anything used in this fragment? It supports reading files, >> regex replacements, and writing files. > > Reading *arbitrary* files and processing binary data. > > It can only read qmake files. No, it can read arbitrary files with cat() function. > And it lacks the transform functions to produce > an hex dump. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
04.06.2019, 04:41, "Thiago Macieira" :
> On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote:
>> This script takes a hideously enormous amount of time to run. I hope it's
>> because that's just a really long line. Found this script that seems to
>> break every 16 bytes:
>> https://github.com/sperner/PowerShell/blob/master/HexDump.ps1
>
> BTW, equivalent Perl script that is a single line and runs in 0.357 seconds:
>
> map { printf "0x%x, ", ord $_ } split //, <>
>
> perl -ne 'map { printf "0x%x, ", ord $_ } split //, <>' < src/corelib/
> mimetypes/mime/packages/freedesktop.org.xml | wc
> 0 1140712 6823656
>
> [xxd runs in 0.23 seconds]
This can be done with qmake if we implement ord
--
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 18:04:49 PDT Thiago Macieira wrote:
> This script takes a hideously enormous amount of time to run. I hope it's
> because that's just a really long line. Found this script that seems to
> break every 16 bytes:
> https://github.com/sperner/PowerShell/blob/master/HexDump.ps1
BTW, equivalent Perl script that is a single line and runs in 0.357 seconds:
map { printf "0x%x, ", ord $_ } split //, <>
perl -ne 'map { printf "0x%x, ", ord $_ } split //, <>' < src/corelib/
mimetypes/mime/packages/freedesktop.org.xml | wc
0 1140712 6823656
[xxd runs in 0.23 seconds]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 17:50:58 PDT Danila Malyutin wrote: > Have you tried running the script with "powershell –ExecutionPolicy Bypass" > ? IRC, this should work for regular non-admin users to. If that does work, > I think you can just pipe the script to "powershell -". That works, thanks. This script takes a hideously enormous amount of time to run. I hope it's because that's just a really long line. Found this script that seems to break every 16 bytes: https://github.com/sperner/PowerShell/blob/master/HexDump.ps1 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Have you tried running the script with "powershell –ExecutionPolicy Bypass"
? IRC, this should work for regular non-admin users to. If that does work,
I think you can just pipe the script to "powershell -".
вт, 4 июн. 2019 г. в 01:54, Thiago Macieira :
> On Saturday, 1 June 2019 08:14:13 PDT Jean-Michaël Celerier wrote:
> > xxd.ps1:
> > param([String]$path)
> >
> > $bytes = [System.IO.File]::ReadAllBytes($path);
> > $size = $bytes.length;
> >
> > $bytes = (($bytes | %{ "0x" + $_ ; }) | Out-String);
> > $content = $bytes -replace "`r",", " -replace "`n","" -replace ".{2}$";
> > $res = "unsigned char foobar[] = { " + $content + " }; + `r`nunsigned int
> > foobar_len = " + $size + ";`r`n";
> > echo $res
> >
> > Feel free to use as you see fit
> > Best,
>
> Thanks. Unfortunately, it didn't go very far:
>
> File C:\Qt\qt5\qtbase\src\corelib\mimetypes\mime\encode.ps1 cannot be
> loaded
> because running scripts is disabled on this system. For more information,
> see
> about_Execution_Policies at
> https:/go.microsoft.com/fwlink/?LinkID=135170.
> + CategoryInfo : SecurityError: (:) [],
> ParentContainsErrorRecordException
> + FullyQualifiedErrorId : UnauthorizedAccess
>
> I know how to turn that off, but I needed Admin privileges to do that. I
> don't
> think it's going to be acceptable for a Qt build.
>
> It's much easier to require people to install Perl.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel System Software Products
>
>
>
> ___
> 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
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Saturday, 1 June 2019 08:14:13 PDT Jean-Michaël Celerier wrote:
> xxd.ps1:
> param([String]$path)
>
> $bytes = [System.IO.File]::ReadAllBytes($path);
> $size = $bytes.length;
>
> $bytes = (($bytes | %{ "0x" + $_ ; }) | Out-String);
> $content = $bytes -replace "`r",", " -replace "`n","" -replace ".{2}$";
> $res = "unsigned char foobar[] = { " + $content + " }; + `r`nunsigned int
> foobar_len = " + $size + ";`r`n";
> echo $res
>
> Feel free to use as you see fit
> Best,
Thanks. Unfortunately, it didn't go very far:
File C:\Qt\qt5\qtbase\src\corelib\mimetypes\mime\encode.ps1 cannot be loaded
because running scripts is disabled on this system. For more information, see
about_Execution_Policies at
https:/go.microsoft.com/fwlink/?LinkID=135170.
+ CategoryInfo : SecurityError: (:) [],
ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnauthorizedAccess
I know how to turn that off, but I needed Admin privileges to do that. I don't
think it's going to be acceptable for a Qt build.
It's much easier to require people to install Perl.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
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) done That (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 100 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
Re: [Development] Deprecation/removal model going into Qt 6
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. > 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? >> 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. > 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) done That (telling the users to just copy&paste the code from the library) defeats the whole point of a software library. > 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 100 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. >> 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. > CoW and SSO are orthogonal optimizations. folly's fbstring has *both*. They are not entirely orthogonal because CoW only works on strings too large for SSO. SSO strings are always deep-copied by design. Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
Den mån 3 juni 2019 kl 20:29 skrev Richard Weickelt : > > > > I think this was asked on the interest list back in January [1]. > > I did search on the Qt mailing lists, but even when I type exactly the > subject of the thread you referred to, google doesn't find it. I would > expect "Official builds configuration options site:lists.qt-project.org" to > bring this post up: > https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but > it seems like google hasn't even indexed it. Strange! Perhaps something for the Qt web server administrators to look at, I would also expect it to be indexed by now. Elvis > > The answer is here: > > > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > Great. Thanks. > > Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
> I think this was asked on the interest list back in January [1]. I did search on the Qt mailing lists, but even when I type exactly the subject of the thread you referred to, google doesn't find it. I would expect "Official builds configuration options site:lists.qt-project.org" to bring this post up: https://lists.qt-project.org/pipermail/interest/2019-January/032221.html but it seems like google hasn't even indexed it. > The answer is here: > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config Great. Thanks. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
Den mån 3 juni 2019 kl 20:04 skrev Elvis Stansvik : > > Hi Richard, > > I think this was asked on the interest list back in January [1]. > > The answer is here: > > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config > > I seem to remember some recent Qt developer thread about making these > more accessible, but can't find it now. Found it, but I remembered somewhat wrong. I was thinking of this note by Volker in the recent "A monologue about platforms in the Qt world" thread [1]: "Why don’t we make the exact way of turning a clean Linux distro-install into a "Qt reference configuration" available to everyone else? The way build machines are provisioned in Coin is rather opaque, even with some of the respective provisioning scripts available in the qt5.git repo [1]. Having to document on a (notoriously outdated) wiki how to set up things to build Qt from source, when we have that knowledge literally codified somewhere for Coin, doesn’t seem effective." So that was more about making the provisioning process for a "reference" build machine more transparent. Elvis [1] https://lists.qt-project.org/pipermail/development/2019-May/035773.html > > HTH, > Elvis > > [1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html > > Den mån 3 juni 2019 kl 18:56 skrev Richard Weickelt : > > > > Hi, > > > > where can I find the configure command lines that have been used for Qt > > binary releases provided at https://download.qt.io/official_releases/qt/ ? > > > > Is there also more information available about the environment they have > > been built on? I am particularly interested in the Linux release. > > > > Thanks > > ___ > > 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
Re: [Development] Configure command lines of official Qt releases
Hi Richard, I think this was asked on the interest list back in January [1]. The answer is here: https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config I seem to remember some recent Qt developer thread about making these more accessible, but can't find it now. HTH, Elvis [1] https://lists.qt-project.org/pipermail/interest/2019-January/032221.html Den mån 3 juni 2019 kl 18:56 skrev Richard Weickelt : > > Hi, > > where can I find the configure command lines that have been used for Qt > binary releases provided at https://download.qt.io/official_releases/qt/ ? > > Is there also more information available about the environment they have > been built on? I am particularly interested in the Linux release. > > Thanks > ___ > 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
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 10:43:44 PDT Konstantin Tokarev wrote: > 03.06.2019, 09:06, "Thiago Macieira" : > > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: > >> I also managed to get that done with a <10 lines of "plain cmake": > >> > >> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0 > >> cb05 7/src/CMakeLists.txt#L46-L54 > > > > Yup, I figured with CMake it would be possible. But I'm trying to get this > > in Qt 5 first. > > Does qmake miss anything used in this fragment? It supports reading files, > regex replacements, and writing files. Reading *arbitrary* files and processing binary data. It can only read qmake files. And it lacks the transform functions to produce an hex dump. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 10:31:14 PDT Thiago Macieira wrote: > A semantic replacement could be used to refactor the code from load() → > load(std::memory_order_relaxed) and loadAcquire() → load(). Another idea is to introduce loadRelaxed() and storeRelaxed() in Qt 5.13, right now, so we can mark load() and store() conditionally deprecated (#ifdef). That way, we can begin converting from load() to loadRelaxed() along the way. When 6.0 comes, we can perform the change from loadRelaxed() to load(std::memory_order_relaxed) with a simple search-and-replace. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
03.06.2019, 09:06, "Thiago Macieira" : > On Sunday, 2 June 2019 22:31:47 PDT Olivier Goffart wrote: >> I also managed to get that done with a <10 lines of "plain cmake": >> >> https://github.com/woboq/moc-ng/blob/7cfa2b65efaf836054977e5974f8f9c23b0cb05 >> 7/src/CMakeLists.txt#L46-L54 > > Yup, I figured with CMake it would be possible. But I'm trying to get this in > Qt 5 first. Does qmake miss anything used in this fragment? It supports reading files, regex replacements, and writing files. -- Regards, Konstantin ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 02:26:05 PDT Lars Knoll wrote: > > == Java-style iteration > > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == > > It's very easy to write quadratic loops with it.remove(), and a review of > > Qt code has shown that some users still use container.remove(), which is > > just as unsafe as with STL iterators. I also noted between 100b/loop and > > 5KiB for four loops of text size savings. > > I’m a bit torn here. On code review I gave a +1 on deprecating them, but I > see that this could lead to a lot of porting effort on user code that makes > extensive use of them. And the problem is that the porting can be > non-trivial in cases where the list gets modified while iterating. So I > think we should most likely keep them for Qt 6. Those are entirely-inline classes, so they don't take space in the library. They've also been completely unchanged for years, so the maintenance cost is minimal. I agree with deprecating but keeping in 6.x. > > == QRegExp == > > > > Is QRegularExpression good enough these days? :) > > > > I’m in favour of deprecating and moving it into a Qt5Support library. As > pointed out, qmake will need it. Possibly a library specifically for QRegExp, like we did for QHttp in 5.0. > > === QAtomic -> std::atomic === > > > > It already is just a thin wrapper around std::atomic, so there's not much > > point keeping it. > > Except that a simple search and replace will change semantics of load(). And > I think that’s not quite acceptable, given that atomics are in quite a few > cases used for performance sensitive code paths. A semantic replacement could be used to refactor the code from load() → load(std::memory_order_relaxed) and loadAcquire() → load(). I wouldn't suggest adding a wrapper that does the mapping. Because we already have one: that wrapper *IS* QAtomicInteger, which already wraps a std::atomic. So either we perform a global, semantic search-and-replace, or we just do nothing. > > === QMutex / QReadWriteLock -> std::*mutex* === > > > > It has too many responsibilities. Where the std knows many different mutex > > classes, Qt folds everything into just two. > > We probably need to keep QRWL around a while longer, since C++ added > > shared_mutex only in C++17. > > The only problem I see with QMutex is that it implements both a recursive > and non recursive mutex in one class. I would consider splitting that up. Already prepared for that. I haven't performed the change, but it's easy to do. I recommend adding QRecursiveMutex right now in Qt 5, with the only difference from QMutex being that it changes the default constructor. That way, code can begin porting, as we deprecate the non-default constructor. QRecursiveMutex will derive from QMutex. I hope that's not a problem. Whether QMutex::lock() can be poor-mans-virtual and perform a recursive lock is up for discussion. As a benefit, neither QMutex nor QRecursiveMutex will allocate memory on Linux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Configure command lines of official Qt releases
Hi, where can I find the configure command lines that have been used for Qt binary releases provided at https://download.qt.io/official_releases/qt/ ? Is there also more information available about the environment they have been built on? I am particularly interested in the Linux release. Thanks ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 06:26:36 PDT Giuseppe D'Angelo via Development wrote: > > QList::prepend has O(1) amortized and O(n) worst case time complexity. > > QVector::prepend has O(mn) (always!) time complexity. > > > > If you are dealing with a large class or struct, e.g. 800 bytes, then the > > QVector operations are 100 times slower than the QList ones! > > 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. Don't forget that QVector is a direct memory access, which is easily predicted by the CPU, so it can read ahead. If you're iterating (accessing!) the elements in QList, you're accessing memory that may not be read-ahead, because it's indirect. It will depend on how the elements were added and the strategy of the memory allocator. Also, please consider the memory considerations. If you have 100 elements of 800 bytes, a QVector will allocate 100*800 + 24 bytes (plus 16 of overhead inside malloc, total 80032 bytes used), whereas QList will allocate 100 * (800 + 8 + malloc overhead) + malloc overhead, for a total of 82416 bytes, or 3% more. Now if your object is 80 bytes instead of 800, the memory usage increase is 29%. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 04:34:27 PDT Kevin Kofler wrote: > Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. And yet, we can look at this exactly as an example: if you set the CPU to long mode (a.k.a., 64-bit mode), then a LOT of previously obsolete instructions are dropped, especially those that were 1-byte opcodes. This is akin to what we're looking for here: if you opt in to greater and newer things, we can drop obsolete things you've had years (or decades, in the case of CPU) to port away from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Monday, 3 June 2019 01:50:26 PDT Giuseppe D'Angelo via Development wrote: > 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). The minimum size for a QString is 3 pointers, which would be 12 bytes on 32- bit. Given we need at least one byte to indicate that it's SSO o not, that would leave an SSO QString limited to 5 chars, which is not very useful. On 64-bit, it would increase to 11 characters. That is better, but given previous histograms of the size of strings in a real-world application (QtCreator), it's leaving a lot on the table. I think the numbers showed that the most common size was 16, but I don't remember if that was bytes or characters. Either way, the drop to the right of the peak wasn't very sharp. The sweet spot is likely to be between 32 and 48 bytes (15 to 23 characters). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> On 3 Jun 2019, at 13:34, Kevin Kofler wrote: >>> 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. > > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. I suppose the same can be said for Linux distros :) But even if we say that Qt is feature complete: the platforms and technologies we sit on top of will continue to develop and change. For example, OpenGL will sooner or later disappear from macOS. NTFS has had symlinks and junctions, which Qt knows precious little about. HTTP/2 is a thing. Some of the changes necessary to stay relevant on these platforms we can make without breaking APIs; some of them we can’t. For example, QFileInfo::isSymLink is a poor API given the file types on NTFS (shortcut files, ie. .lnk; junctions, which are like hard-links for directories; symlinks; files; directories). Of course, we can keep it around forever while introducing a more nuanced API, but the code that implements the old API is a mess to maintain as well, and will likely interfere with a clean and maintainable implementation of a better API. In addition, sometimes we don’t get it right the first time. In fact, any strategy that is based on the assumption that “we get it perfectly right the first time so that we never have to change it” is bound to fail. I crafted the first version of QAccessible, and I wonder how many of you can be bothered with implementing your accessbility interfaces when you implement your custom widgets or QML controls. That ultimately affects real people, and if we have to break API or ABI to make it more likely that all UI elements are accessible, then let’s please do that. It’s always a trade-off, and each case needs to be discussed. Nobody is recommending that we are mindlessly removing or changing things just because we can. But going the other extreme and saying "nothing must ever change because people will have to change their software” is not better. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
Il 03/06/19 13:34, Kevin Kofler ha scritto: Giuseppe D'Angelo via Development wrote: Il 03/06/19 00:08, Kevin Kofler ha scritto: What you call "obsolete functionality" is functionality that existing code relies on and rightfully expects to remain there. Rightfully? By what right exactly? APIs in libraries are meant to be used. I consider it an entirely reasonable expectation by developers using the APIs that they will not be removed under them because the library developers consider them "obsolete". Imagine the chaos if Intel or AMD decided to remove some random "obsolete" x86 instructions from their CPUs! x86 has kept backwards compatibility with every single instruction for more than 30 years. This is the standard software libraries should be held to, too. Nice try: https://rationalwiki.org/wiki/Straw_man#Forms Specifically: moving the focus from a GUI framework's API to a foundational computer architecture design (which must provide much stronger guarantees). 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. 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. 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. Qt has long reached a point where it can be considered complete. Its main selling point is portability to many different platforms rather than some specific feature. Additional features don't necessarily need to be in the main Qt library, but can be in community-developed addons such as KDE Frameworks or such as the many third-party Qt-based Free Software libraries out there. (They can also be in Qt-Company-developed Qt Solutions if there is manpower left for that.) 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. Qt 6 wants to do that, and the point of this thread is how to minimize the pain. Just compare the size of the Qt 3 tarball with the size of the Qt 5 monolithic tarball. This is not the result of keeping old APIs around, but of feature creep. "Creep" is questionable; and anyhow off-topic. So I disagree with the assertion that Qt needs more features to remain competitive. And I disagree with this. And even assuming to stop adding new feature,s the _current_ feature set may need refactoring and redesigns, which may mean API breaks. 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"). The Q_FOREACH to ranged for change is not as easy to port to as people think, because there are at least 2 pitfalls when porting to ranged for: 1. you have to add qAsConst or equivalent or you will be deep-copying your implicitly-shared CoW container, 2. code that was changing the container during the iteration, which worked just fine with Q_FOREACH (because the iteration would still be over the original unchanged container), will now crash without warning. Even qAsConst will not help you get a warning or error for it, because it only constifies the reference for the ranged for itself and not for the code within it. This is effectively deprecating a safe construct for an unsafe one. This is not the intended port, because it's not scriptable. Moving to a range-based for is the long-term solution, but that requires checking all usages. 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) done What's the difference, then? For your code, minimal (just use another macro). But for Qt, that it stops supporting Q_FOREACH, teaching its usage, and advocating for it. 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:
Re: [Development] Qt 6 story
On 6/3/19 2:35 PM, Bernhard Lindner wrote: What would be your story proposal? "Make Widgets great again"? That would be one I would like to see. But the story I'm actively working on is about a different Qt/Quick framework. I hope, that we are allowed to give a presentation of what this is supposed to be at the Qt World Summit. Unfortunately the Qt project seems to be clueless about how to deal with projects being developed outside. I tried to get an answer to the simple question how my work could be related to the Qt project. But even after a face to face meeting with Lars I never got any type of response. Neither positive nor negative - only silence. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt Design Studio 1.2 final is released
Hi, Qt Design Studio 1.2 final is released today, see https://blog.qt.io/blog/2019/06/03/qt-design-studio-1-2-released/ Big thanks to everyone involved! Best Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 6 story
> Actually each major release should have a story, that has to do with > some sort of innovation that might require to remove old stuff. Very good statement. The current implicit stories seems to be: "Throw out some parts we can't afford" and "Replace the builds system". Which are both not a very attractive from the application developers point of view. Did I miss something? What would be your story proposal? "Make Widgets great again"? "Modernize the language to C++17" would be a possible story as well (especially teaching moc to handle templates). Any proposals for a Qt 6 story? I hope my suspicion is wrong that Qt has spent so much on a few cash cows that it is no longer capable of any other major advances (but must even go backwards, see XML thread). -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> > > > So, yes, this is borne out of frustration with the lack of maintenance > > > > of QtCore plumbing. I don't see that changing and I acknowledge and > > > > understand that the focus of development has shifted towards QML. > > > Suppose you implement all planned actions for Qt6 (see your original > > > e-mail). Are > > > the > > > remaining components (those that are neither deprecated nor removed) of > > > Qt6 well > > > maintained and are there enough staff available not only to maintain them > > > indefinitely > > > but to actively develop them further? > > > > No answer to my question above? > > Who do you expect an answer to this question from? > > The Qt Company? The Qt community? Marc? Thiago? Whoever believes being able to make a realistic assessment. If there is no such person/group in this list, which can do an estimate how much of Qt is affordable, an important aspect of the Qt 6 discussion can not actually be discussed. How can Marc think about removing (or significantly changing) Qt due to ressource limits or new strategic goals if the limits or goals are unknown? Actions out of frustration are never a good idea. And pushing into a (technical) direction that does not solve the underlying (strategical) problem is futile. -- Best Regards, Bernhard Lindner ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 1:34 PM, Kevin Kofler wrote: So I disagree with the assertion that Qt needs more features to remain competitive. Come on - a toolkit ( Qt/Widgets ) for writing user interfaces, that does not make use of the graphics hardware, is begging for being replaced. Quick Controls 1 was once supposed to be such a replacement, but it failed to a degree, that it became a candidate for removal for Qt6. A technology that needs more than 30 QObjects to create a button simply has no rights to survive only because of compatibility considerations. Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
> APIs in libraries are meant to be used. I consider it an entirely reasonable > expectation by developers using the APIs that they will not be removed under > them because the library developers consider them "obsolete". Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. This is the standard > software libraries should be held to, too. This is common practice to mark API deprecated in one major release and remove them in the next one. It helps not clutter an interface and keep it fresh and updated. Yes, it might break some code, but people will be receiving compiler warnings that some functionality has been marked as not recommended for using, and will have a plenty of time to replace it with recommended solution. Regarding CPU, this is another level. I don't think that this comparison is suitable. I don't want Qt to be in C++ situation: some usable subset and a pile of... old things, left for backward compatibility. Fine, it's already in, but there are no reasons to make it worse. As the framework maintainers we have to be more reasonable, I would say. > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. Qt is modular and is going to be more modular. Are there any problems with not using/building/supplying some modules? Introducing (and maintaining after) new features is cool. Old and unused should be eliminated without mercy :) On 6/3/19 1:34 PM, Kevin Kofler wrote: > Giuseppe D'Angelo via Development wrote: > >> Il 03/06/19 00:08, Kevin Kofler ha scritto: >>> What you call "obsolete functionality" is functionality that existing >>> code relies on and rightfully expects to remain there. >> Rightfully? By what right exactly? > APIs in libraries are meant to be used. I consider it an entirely reasonable > expectation by developers using the APIs that they will not be removed under > them because the library developers consider them "obsolete". Imagine the > chaos if Intel or AMD decided to remove some random "obsolete" x86 > instructions from their CPUs! x86 has kept backwards compatibility with > every single instruction for more than 30 years. This is the standard > software libraries should be held to, too. > >>> 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. > Qt has long reached a point where it can be considered complete. Its main > selling point is portability to many different platforms rather than some > specific feature. Additional features don't necessarily need to be in the > main Qt library, but can be in community-developed addons such as KDE > Frameworks or such as the many third-party Qt-based Free Software libraries > out there. (They can also be in Qt-Company-developed Qt Solutions if there > is manpower left for that.) > > Qt has also become larger and larger over time (despite the removal of APIs > considered obsolete). Just compare the size of the Qt 3 tarball with the > size of the Qt 5 monolithic tarball. This is not the result of keeping old > APIs around, but of feature creep. > > So I disagree with the assertion that Qt needs more features to remain > competitive. > >>> 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"). > The Q_FOREACH to ranged for change is not as easy to port to as people > think, because there are at least 2 pitfalls when porting to ranged for: > 1. you have to add qAsConst or equivalent or you will be deep-copying your > implicitly-shared CoW container, > 2. code that was changing the container during the iteration,
Re: [Development] Deprecation/removal model going into Qt 6
Giuseppe D'Angelo via Development wrote: > Il 03/06/19 00:08, Kevin Kofler ha scritto: >> What you call "obsolete functionality" is functionality that existing >> code relies on and rightfully expects to remain there. > > Rightfully? By what right exactly? APIs in libraries are meant to be used. I consider it an entirely reasonable expectation by developers using the APIs that they will not be removed under them because the library developers consider them "obsolete". Imagine the chaos if Intel or AMD decided to remove some random "obsolete" x86 instructions from their CPUs! x86 has kept backwards compatibility with every single instruction for more than 30 years. This is the standard software libraries should be held to, too. >> 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. Qt has long reached a point where it can be considered complete. Its main selling point is portability to many different platforms rather than some specific feature. Additional features don't necessarily need to be in the main Qt library, but can be in community-developed addons such as KDE Frameworks or such as the many third-party Qt-based Free Software libraries out there. (They can also be in Qt-Company-developed Qt Solutions if there is manpower left for that.) Qt has also become larger and larger over time (despite the removal of APIs considered obsolete). Just compare the size of the Qt 3 tarball with the size of the Qt 5 monolithic tarball. This is not the result of keeping old APIs around, but of feature creep. So I disagree with the assertion that Qt needs more features to remain competitive. >> 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"). The Q_FOREACH to ranged for change is not as easy to port to as people think, because there are at least 2 pitfalls when porting to ranged for: 1. you have to add qAsConst or equivalent or you will be deep-copying your implicitly-shared CoW container, 2. code that was changing the container during the iteration, which worked just fine with Q_FOREACH (because the iteration would still be over the original unchanged container), will now crash without warning. Even qAsConst will not help you get a warning or error for it, because it only constifies the reference for the ranged for itself and not for the code within it. This is effectively deprecating a safe construct for an unsafe one. >> 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. I'm speaking exclusively of time complexities. The space only matters when it goes into the formula for the time, which is the case for QVector. QList::insert and QList::removeAt have O(n) time complexity. QVector::insert and QVector::removeAt have O(mn) time complexity. QList::prepend has O(1) amortized and O(n) worst case time complexity. QVector::prepend has O(mn) (always!) time complexity. If you are dealing with a large class or struct, e.g. 800 bytes, then the QVector operations are 100 times slower than the QList ones! > 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. For me, the best general purpose container is the one that makes it hardest to run into big performance bottlenecks. The point being that it should be GENERAL purpose, i.e., work efficiently for as many use cases as possible, even if it requires compromises for some common ones. So an O(n) container is better than an O(mn) one, even if it is often marginally slower. And a container with prepend optimization is better than one without it. I used array-of-pointer data structures almost exclusively even in plain C code and before Qt even introduced QList as it stands now. I find QList's API that hides the pointer dereferences, the allocations to hold the value copies, etc. (i.e., all the tedious parts of
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> On 1 Jun 2019, at 21:20, Bernhard Lindner wrote: > > Am Mittwoch, den 29.05.2019, 23:34 +0200 schrieb Mutz, Marc via Development: > >>> So, yes, this is borne out of frustration with the lack of maintenance >>> of QtCore plumbing. I don't see that changing and I acknowledge and >>> understand that the focus of development has shifted towards QML. > >> Suppose you implement all planned actions for Qt6 (see your original >> e-mail). Are the >> remaining components (those that are neither deprecated nor removed) of Qt6 >> well >> maintained and are there enough staff available not only to maintain them >> indefinitely >> but to actively develop them further? > > No answer to my question above? Who do you expect an answer to this question from? The Qt Company? The Qt community? Marc? Thiago? Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Sat, 1 Jun 2019 14:36:12 +0200 André Pönitz wrote: > On Fri, May 31, 2019 at 01:24:13PM +, Volker Hilsheimer wrote: > > The overall goal here is to make sure that we don’t have to carry > > poorly designed architecture or APIs around with us throughout the Qt > > 6 series, and as long as we care about binary and source compatibility > > within a major series, doing what we can for Qt 6.0 (and doing it > > right) is the only option we have. > > The problem is that we as a whole do not agree what "poorly designed > architecture or APIs" means in detail anymore, sometimes even on a very > fundamental level. > > E.g. the previous consent on Qt providing consistency and convenience > is challenged regularly by some. I don't think there is an actual controversy there; the term "some" already seems to be an overstatement. Christian ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 6/3/19 10:50 AM, Giuseppe D'Angelo via Development wrote: How is this even an argument? Qt will need to evolve and acquire features to remain competitive. The probably most important module - Qt/Widgets - sits on a graphic stack, that had been identified as not being competitive many years ago. The only reason why the module ( = Qt on the desktop ) remains competitive is the lack of competition - including Qt/Quick modules. My expectation for a major release like Qt6 would be to see Qt/Widgets being migrated to the newer graphic stack - even if this would result in substantial API incompatibilities. Actually each major release should have a story, that has to do with some sort of innovation that might require to remove old stuff. But Qt6 does not seem to have something like this and why is it necessary then f.e to remove deprecated/failed modules like QC1 ? Uwe ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Also here going back to the start of the thread (as I was offline for some days for a long weekend): > On 29 May 2019, at 12:53, Mutz, Marc via Development > wrote: > > Hi, > > Here's a list of stuff I consider has served it's purpose and is no longer > needed, with respective replacements: > > = Priority 1 = > > == QSharedDataPointer / QExplicitlySharedDataPointer == > > These are basically Qt-internals, and should never have been public in the > first place. It's _because_ they are public that we have two of them, and > soon a third one (properly non-public): > https://codereview.qt-project.org/c/qt/qtbase/+/115213 That commit's message > also explains what's wrong with the QSDP and QESDP. > I see no reason at all for removing those, quite to the contrary. They are very helpful for building refcounted classes (explicitly or implicitly shared). > > == Q_FOREACH -> ranged for loops > (https://codereview.qt-project.org/c/qt/qtbase/+/147363) == > > Q_FOREACH is less readable (because it allows mutating the container under > iteration), and produces _a lot_ of code. It also is intrinsically tied to > just a few Qt containers (excluding QVLA). Ranged for loops work on anything, > incl. a C array. Also, as a macro, it will continue to cause problems down > the road (e.g. with modules). Being a macro also means that it cannot deal > with value_types that contain a comma. > > === related: Q_FOREVER -> for(;;) === > > Suggested by Lars in ibid. Basically because it's a macro. Right, I suggested this, mainly because I don’t think Q_FOREVER is nicer than for(;;) or while(true). But I don’t mind the macro and if it’s widely used we could simply keep it (it doesn’t cost us anything to have it). > > > == Java-style iteration > (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == > > It's very easy to write quadratic loops with it.remove(), and a review of Qt > code has shown that some users still use container.remove(), which is just as > unsafe as with STL iterators. I also noted between 100b/loop and 5KiB for > four loops of text size savings. I’m a bit torn here. On code review I gave a +1 on deprecating them, but I see that this could lead to a lot of porting effort on user code that makes extensive use of them. And the problem is that the porting can be non-trivial in cases where the list gets modified while iterating. So I think we should most likely keep them for Qt 6. > > > == QScopedPointer -> std::unique_ptr == > > Suggested by Thiago on https://codereview.qt-project.org/c/qt/qtbase/+/261553 > > I agree. We now have std::unique_ptr, and it's movable. QScopedPointer had > the problem that it didn't know what it wanted to be: boost::scoped_ptr or > std::unique_ptr. A real scoped pointer would not offer release(), a > unique_ptr would need to provide move semantics. QScopedPointer has > release(), but no moves (were proposed, but not accepted). > > > == QLinkedList -> std::list > (https://codereview.qt-project.org/c/qt/qtbase/+/261421) == > > Of the Qt containers, this one is the most-unused (in Qt code), as well as > the one that's furthest behind it's STL counter-part. Whenever I use > std::list, I use it for splice(), a function that just cannot be added to a > CoW container. Qt is already almost completely QLinkedList-free. Let's bury > QLinkedList. It’s not used a whole lot, and I’m not against deprecating it. But do we need to remove it for 6.0? Or maybe go the route we thought about for other containers as well and have it wrap a std::list. ie. remove our implementation, keep our API. > > > == qHash() -> std::hash == > > Suggested by Lars in https://codereview.qt-project.org/c/qt/qtbase/+/261819. > To be precise, he's suggesting to specialise std::hash and have qHash() call > std::hash. > > Only problem I see so far is that std doesn't provide us with a tool to hash > composites. E.g. there's no std::hash for std::tuple (which would mean we can > std::tie the members and hash the result), and only C++17 adds some kind of > raw bits hashing (via std::string_view). We'd need to provide these building > blocks ourselves, which can be done, but it means we'll have at least _some_ > qHash()-like functions we need for std::hash<> implementations. > > Actual problem? I think this depends on whether we use std::unordered_map to implement QHash or not. > > > == QPaintDevice == > > I'd like this to become a static interface. In very shortened terms: > everything that has a QPaintEngine *paintEngine() method is a paint device. > QPainter's ctor would become a template and do the virtual dispatch > internally, just like Sean Parent's document type in C++ Seasoning. > > This would solve a lot of problems: QWidget would no longer need to use > multiple inheritance, and QImage and QPixmap would become proper value types, > without virtual functions that create problems with move semantics and > swapping. I like this idea. It
Re: [Development] Deprecation/removal model going into Qt 6
Going back to the beginning of the thread. > On 31 May 2019, at 14:50, Giuseppe D'Angelo via Development > wrote: > > Hi, > > It seems to me that many emails in the earlier deprecation thread were from > users concerned by the problem of removal of functionality. This is not an > old story. > > However, apart from the specifics of why deprecating a certain class / what > to replace it with / etc., there's a bigger thing that needs to be clarified, > which is: what is the deprecation/removal model going into Qt 6. > > > It is my understanding that the current plan is to: > > * _remove_ from Qt 6.0 any API deprecated in Qt 5.x (for any x); > > * in order to ease the migration from Qt 5, any API that is going to be > removed/changed in Qt 6.0 (for any reason) is also going to be deprecated in > Qt 5.latest (5.15 LTS, AFAIU). > > > I guess that the idea is that the port to Qt 6 can then happen in multiple > steps: > > 1) port to Qt 5.latest; > 2) (enable and) fix all deprecation warnings; > 3) port to Qt 6. > > > If this is still the plan, I must say I am not a huge fan of it. It has all > the premises to be another Qt3->4 hit. Specifically: Why do you think so? The plan above is actually stricter than what we did when moving from Qt 4 to Qt 5 (where (2) was only partially done). So I believe that the plan above should not make it harder to move from 5 to 6 than the Qt4->5 move. Unless we go completely crazy with deprecations in 5.15 of course, but that’s something we should be careful about. > > * It assumes that any breaking change will happen in Qt 5 first, signalled > via deprecation macros, then Qt 6 will simply remove the deprecated parts. As > we're already seeing with e.g. QList, this is not happening for all the > possible cases, meaning the porting steps above are incomplete and there will > be some extra porting fallout to take into account. > > * It does not let users move away at their own pace. Qt 6.0 will be > inaccessible for existing Qt 5 software until one has ported away from every > deprecated API. If we keep deprecating things (and add replacements) up to > 5.latest, then this also makes it complicated for users to build libraries > and components targeting both Qt 5 and 6. Removing deprecated functionality always forces the users hands. But at some point it has to be done, or we can never drop anything. And btw, I’m not a fan of simply removing/deprecating tons of things without good reason (so I’m opposed to many of the things Marc brought up in the deprecation thread he initiated). > > Such libraries may end up to only be able to target Qt 5.latest and 6 > together, without resorting to #ifdefs or similar machinery in their code; > the reason is that only 5.latest would have the required replacement APIs for > the ones deprecated in 5.latest / removed from 6.0. > > * It does not make a distinction w.r.t. _when_ an API has been deprecated. > IMHO there is a difference between an API deprecated in 5.0 and one > deprecated in 5.15; users had much more time to port away from the former. > Dropping them both on the floor in 6.0 seems very unfair to me, again forcing > users to tackle the deprecation _immediately_ if they want to port to Qt 6. We can consider a staged approach, but there might be some cases, where we need to do a hard cut to get rid of some very heavy luggage for Qt. Where it doesn’t hurt us as much, deprecating and keeping it around in 6.0 is something we could discuss. > > * It does not make a distinction between APIs for which we have a > straightforward / immediate / scriptable (!) replacement, and APIs for which > we don't (yet we'd like to get rid of them). Keeping the latter APIs as > stable and supported in Qt 6.0 means keeping them since 7.0 and then face > have the same problem again. But simply dropping them means pain for users. As a general rule, we shouldn’t drop something where we do not have a replacement available. But there might be exceptions (XMLPatterns come to my mind). Cheers, Lars > > > Given all the work that went into adding deprecation macros during Qt 5 > lifetime (even the multiple incantations of them), would it be possible > somehow to avoid most of the source breaks caused by removal of the > deprecated APIs? I know that it's easier said than done, as it would require > doing this on a API-by-API basis rather than turning a big switch; but we > could find some compromise somewhere. > > > Anyhow, flame away. > > Thanks for reading, > -- > 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 > > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development ma
Re: [Development] Deprecation/removal model going into Qt 6
> On 3 Jun 2019, at 08:00, Thiago Macieira wrote: > > On Sunday, 2 June 2019 16:46:00 PDT Manuel Bergler wrote: >> Well, something has to give. Either >> a) Qt can never remove superseded APIs and classes (which is what >> you suggested previously) and will eventually collapse under its own >> weight, or >> b) Distributors have to deal with the fact that some software >> doesn't port and have to ship every version of qt side-by-side, or >> c) The software that doesn't port has to deal with the fact that it >> will be dropped by distributions. But any software with sufficiently >> many users to warrant packaging by the distributors should be able to >> find a maintainer that at least can keep it compiling. > > The answer is a mix of (b) and (c). Distributions don't ship every version > side by side, just one of each major version. Software that doesn't port gets > dropped when that major version is dropped. Yes. (a) is not an option if we want to keep Qt alive in the long term. Cheers, Lars ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
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 QString SSO 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 256 bytes (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. * 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? QString with SSO will make Qt5List 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, QList, QList, and so on, see the other email. ***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 Developm
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Saturday, June 1, 2019 5:36:35 AM CEST Thiago Macieira wrote:
> On Friday, 31 May 2019 10:13:52 PDT Thiago Macieira wrote:
> > rcc should be un-bootstrapped. The only use inside QtCore is for the MIME
> > type database. We don't need a resource, though it compresses really well
> > (roughly 10:1 with zstd). I'd simply make that a read-only sharable
> > variable, which we can easily create with a C++11 raw string.
>
> https://codereview.qt-project.org/c/qt/qtbase/+/263548
>
> Unfortunately, MSVC doesn't want to cooperate:
>
> .\qmimeprovider_database.cpp(1270): fatal error C1091: compiler limit:
> string exceeds 65535 bytes in length
>
moc had similar problem, it was solved by generating something like that:
struct {
char[65535]
char[65535]
}
instead of a string.
Cheers,
Jędrek
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
