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.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
