[Development] Views

Elvis Stansvik elvstone at gmail.com
Thu Jun 6 13:56:49 CEST 2019


Den tors 6 juni 2019 kl 13:40 skrev Mutz, Marc via Development
<development at qt-project.org>:
>
> On 2019-06-06 12:24, Lars Knoll wrote:
> >> On 6 Jun 2019, at 11:08, Simon Hausmann <Simon.Hausmann at 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 at qt-project.org
> https://lists.qt-project.org/listinfo/development


More information about the Development mailing list