[Development] Views

[Lars Knoll]

> On 6 Jun 2019, at 13:39, Mutz, Marc via Development <development at qt-project.org> wrote:
> 
> 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.

The comment above was aimed at our APIs and towards our users, not about how we implement things internally.
> 
> 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.

You have in general been advocating lately to remove/deprecate lots of Qt API in favour of STL. This is what I referred to, not implementation details in our code.

Removing the usage of a QMap for a mapping of 5 values is the right thing to do. Whether we need lower_bound() for that and a sorted list, or simply an unsorted vector where we iterate until we find the right value doesn’t matter too much in this case. Performance wise both would probably be equivalent :)
> 
> 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.

Nobody here said that. I also believe those changes that you proposed got approved to the largest degree.

If you read what I said earlier, I also said that in most cases better data structures and algorithms will lead to more readable code. I am not opposed to using those in Qt, quite the opposite.

> 
> 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.

Nobody ever said that as far as I can tell. What people said is that there are cases, where a loop is just as efficient and easier to read (e.g. when searching for an entry). And in that case it’s fine to simply use that. So please stop turning the meaning of what people said around like that.

Lars