On 2019-06-06 11:08, Simon Hausmann wrote:
Am 06.06.19 um 10:42 schrieb Mutz, Marc via Development:
[...]
Do you guys _actually_ think that readability of Qt code trumps
_everything_?
For me the answer is "no". I believe that for the majority of Qt code
we
should strike for a compromise - as opposed to "trumping everything" -
and certainly use more low-level code in areas that we know are
particularly performance sensitive. That includes for example the
software rasterize, the inside of QString or the text shaping.
These are areas where we need offensive _optimisation_, yes, I agree.
[...]
Yes, we have an obligation to our users and we have an obligation to
the
rest of the community that's developing Qt. I strongly suspect that you
are in fact in agreement with me that the code that we have in code
must
strike that compromise so that others in the project continue to feel
comfortable to read, understand and modify the code and yet we can
deliver a product to our users that's competitive in terms of
performance (run-time, code size, etc.).
Indeed, we agree here.
What we appear to disagree on is the exact line of complexity / style /
noise.
To put it poignantly: We disagree on our judgement of the ability of Qt
devs to learn the STL. I think they can, you think they can't.
We also don't have to see eye to eye on this, I think. I think
that simply leaves us with the established decision making process,
where with our changes we have to appeal to the approvers in the
project
and rely on the lazy concensus here. In the context of that, I note
your
strong objection to Joerg's statement while I agree with Joerg.
As I note Lars' approval of the change from QVector to std::vector, even
though it sprinkled int/size_t casts all over the place.
You appeal to the status quo. Replacing a QMap with a QHash for a
five-entry data stucture is not a change, it's churn. I'd like to
educate people in how to make simple data structures do what they need
from them, without resorting to complex data stuctures. Does his appeal
to reviewers? Probably less so. Is it necessary? Yes, I think so.
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?
You can mentally replace it with "fan club": Some people act as if Qt's
API is superior to all other APIs. Well, it's not. It has weaknesses
too, it's ugly, too (QGradientStop::first?!), and people should rise
above this and see it for what it is: An API with a certain set of
principles, not always honoured, also ageing sometimes. It's use should
be justified the same was as the use of the STL is: what's better (for
any sense of of the word). It's not bad just because it's not Qt.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
