[Development] Views

[Elvis Stansvik]

Den tors 6 juni 2019 kl 13:56 skrev Elvis Stansvik <elvstone at gmail.com>:
>
> 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 :)

Also, Qt developers will of course have to work out what policies you
want to have for the implementation of Qt, but my take as a user is
that I don't have the expectation that Qt is always optimal, just
because it is a library. I trust that Qt developers always make
case-by-case judgement between 1) API for the user, 2) Size/speed of
the code, 3) Maintainability of the code. The case-by-case because
there are some parts which quite obviously won't be called often, or
classes which won't have many instances.

For example in the QDrag patch, where you made an ad-hoc inline
implementation of a mapping on top of a vector (roughly doubling the
LoC), instead of using a datatype that expresses what it is (QMap), in
order to save 4KiB and some allocations, I guess it's to be expected
that some people disagree with the priorities and give you a -1. I
would say I'm on the fence on that particular one. But perhaps the
best course of action is, as was suggested earlier, to make a helper
datatype for small mappings? Maybe everyone would be happy then? If
such optimizations become common, and the pattern repeated at say 20
places, the code is undoubtedly going to become more brittle and
harder to maintain.

Elvis

>
> Elvis
>
> >
> > Thanks,
> > Marc
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > https://lists.qt-project.org/listinfo/development