[Development] Views

Mutz, Marc marc at kdab.com
Thu Jun 6 13:39:34 CEST 2019


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.

Thanks,
Marc


More information about the Development mailing list