Re: [Interest] Set manipulation in Qt 6
Il 21/06/20 20:07, Elvis Stansvik ha scritto:
I'm all for Qt offering faster way to do things. I expect that. But I
also wonder: Why remove the slower alternative for those who value
readability over optimality in the cases where the extra performance
is not needed? In the docs, the slow alternative could have pointers
to the fast alternative, and the user could make an informed choice.
Let me elaborate on what I commented on the bug report:
1) no API should lead to naturally writing bad code;
2) no API should encourage premature pessimization;
3) APIs should encourage the natural discovery of the best tool for a
given job. If your job is to remove duplicates, the API should favour an
algorithm for that, not the toSet().toList() combo, which is just an
antipattern!
4) as developers of Qt: we must care about all of the above; and bad
habits on user side shouldn't result in bad APIs, in the name of
convenience or whatever;
5) ultimately, the most direct replacement of toContainer() is
container | ranges::to
which isn't that much of an extra burden to learn / to type rather than
toContainer(), and it's also obviously more general.
---
In other words: if you "don't care", you can just replace list.toSet()
with list | ranges::to. You can do it today, using just a C++14
compiler (and you need a C++17 compiler anyhow if you're aiming for Qt 6).
Back on to OP's issue, with this code using deprecated APIs:
QSet
missingKeys{customLines.keys().toSet().subtract(customLinesColor.keys().toSet())};
Then the "don't care" port can be done by something like:
QSet missingKeys = customLines.keys() | ranges::to;
missingKeys.subtract(customLinesColor.keys() | ranges::to);
If nobody ever told you about toSet(), and only told you about
ranges::to, would you be upset by toSet()'s deprecation?
My 2 c,
--
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
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Set manipulation in Qt 6
On Sat, Jun 20, 2020 at 12:34:11PM +0200, Giuseppe D'Angelo via Interest wrote: > With my hat of the guy going around and deprecating toSet() and friends: the > rationale for these deprecations is the terrible code that those methods > encourage, and the While I sympathize to some degree with the performance motivation behind this kind of removal of convenience functionality this has to be put into perspective of the price you charge: We had to spent a significant amount of our time during the last year to keep up with the deprecations within the last releases in the 5.x series. This includes re-inventing parts of the abandoned qalgorithm as part of our code base. The toSet/toList changes alone involved touching 200+ locations in the code base and I am not aware of even a single noticable performance improvement as a result. A back-of-the-envelope calculation with generous assumptions on user count and usage frequency makes me believe that the accumulated win on saved computer time does not even offset the amount of manual work that had to be spent on these changes. On top of that goes the more complex and consequently harder to read re-written code, plus the chance of introduction of actual regressions in the code. The latter is btw not just theoretical, I noticed only last Friday the hard way that blindly replacing QLinkedList by std::list can transform previously correct and working code into a crash. Having to thoroughly check each and every such replacement only to get in the best case the same functionality as before is an awful value proposition. To summarize: If you despise wasting cycles for convenience that's fine. Assuming that everyone else shares this preference is already odd. Making other people pay for this is simply wrong. > (Which brings me to my second crusade, try stop encouraging the usage of Qt > containers, as their API is full of holes and doesn't play nice with > algorithms or ranges. But it's enough for this mail.) If you want to use Qt without Qt that's fine. But please stop making other people suffer from your choices. Andre' ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
