On 2019-06-06 09:47, Simon Hausmann wrote:
[...]
However I don't find your arguments that find_if/lower_bound is not
harder to read convincing. I continue to agree with Joerg and Tor Arne
and feel that the API of the associative containers results in code
that
is more compact, visually less noisy and consequently easier to read.
[...]
Well, yes, put that way, sure, it's more (source) code, and more noisy.
*But* it's not "hard to read" in the sense that you stare at it and
can't figure out what the hell the code is doing. For that, you need to
go to qgesturemanager.cpp (which, incidentally uses all the nice Qt
container APIs to make an unreadable mess of things). Algorithms need
some getting used to, but if people would stop fighting the urge to bash
everything looking even remotely STL-ish as unreadable, they would find
that it's quite ok.
The question I have, after all this talk about readability, however, is
this:
Do you guys _actually_ think that readability of Qt code trumps
_everything_? So much so that even the use of a find_if (which could be
replaced by a raw for loop) or lower_bound (which could not; only 10% of
Berkeley CS students managed to write it correctly in a 2h time limit)
is unacceptable?
If that is so, who cleans up qstring.cpp from all the SIMD stuff?
I'd rather agree with our Chief Maintainer who said, on
https://codereview.qt-project.org/c/qt/qtbase/+/114327:
IMO, we should use whatever is most efficient for our internal data
structures.
IMO, that hits the nail on the head: we have an obligation to our users
to use the most efficient data structure (and, by extension, looping
construct) we possibly can, and can't just pop in the first data
structure that comes to mind.
IMNSHO, you can optimize for readability in your own app and see whether
you sustain in the market. In a library, used on millions of machines
every day, spending 8KiB (or 4KiB, or just 1KiB) just to use a slightly
less noisy code version is - sorry - selfish. If you contribute to Qt,
you should be putting yourself in the service of it's users.
I have the feeling that some participants of these discussions thought
they joined an adulation club for Qt API lovers instead.
Thanks,
Marc
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
