Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development <development@qt-project.org>: > > On 2019-06-06 12:24, Lars Knoll wrote: > >> On 6 Jun 2019, at 11:08, Simon Hausmann <simon.hausm...@qt.io> > >> wrote: > >> > >> Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development: > [...] > >>> I have the feeling that some participants of these discussions > >>> thought > >>> they joined an adulation club for Qt API lovers instead. > >> > >> I don't quite understand what you're trying to say with adulation > >> club > >> for Qt API lovers. Could you explain this, please? Am I supposed to > >> feel > >> insulted or offended? > > > > Not sure what to say to this neither. > > > > Let’s remember that a large part of Qt’s success has been due to > > its API. Making programming easy and fun has been at the core of what > > we’re doing and it has to stay that way, or we’re really loosing > > the core of what made and makes Qt successful. > > > > Many of our users strongly feel (and IMO rightfully so) that STL is a > > difficult API that’s maybe very powerful for the things it does, but > > at the same time hard to use and where it’s very easy to get things > > wrong. Qt solved a lot of that pain. > > > > Yes, our classes might not be quite as performant in all cases, but > > they do get the job done. And they do help our users to write code > > they feel comfortable maintaining, something that is in most cases > > much more important to them than another few percent of performance. > > You are equating Qt users and Qt implementers. You can maintain the Qt > API, but use more efficient data structures in the implementation. You > seem to be implying that these two things cannot be separated. > > None of the changes where I replaced QMap changes the public API at all > (except adding an overload because we can). No user is affected by this > in any way, except that they have a few pages of memory more free than > before. > > Please explain to me how any of those changes makes _users_ of Qt have > to revert to the STL? > > And please explain to me how it can possibly be worthwhile to generate > 8KiB of code _just_ to not have to use lower_bound? Which argument could > *possibly* be made against a lower_bound? Esp. seeing as many attempts > to write one by hand have failed. I remember a bug about shortcuts being > mapped to the wrong key, because the hand-rolled binary search was > unstable. > > I'm sorry, but we have a lot of code that is less readable than any of > the changes I uploaded. It just cannot be an argument to say that it's > unreadable because it uses an STL algorithm. This sentiment has caused > so very, very many quadratic loops because people get the impression > that std::remove_if is toxic, and in each one the solution was to use > remove_if, because the hand-rolled alternative would be totally > unreadable. > > I'm sad to see that Qt devs think so lowly of themselves as to be unable > to understand a piece of code that uses an STL algorithm. Really. I'm > out of words.
Since you've repeated this a few times now: I don't think anyone has suggested that they cannot understand the STL code. What they have said is that the find it _less_ readable/maintainable, not _un_readable. Someone jump in and correct me if I understood them wrong, in which case I join Marc in the shocked camp :) Elvis > > Thanks, > Marc > _______________________________________________ > 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