[Interest] Set manipulation in Qt 6

[Elvis Stansvik]

Den sön 21 juni 2020 kl 19:23 skrev André Pönitz <apoenitz at t-online.de>:
>
> 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.

We've also done some work porting away from these in our codebase, and
likewise, no noticeable performance improvement. This is no
coincidence - we know what we're doing, and were not using these in
performance sensitive code. This is not premature pessimization, but
simply about sound prioritization. In these places, we would have
preferred to keep the more readable toSet etc. So I can sympathize
with you André.

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.

Elvis

>
> 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 at qt-project.org
> https://lists.qt-project.org/listinfo/interest