[Development] Views

Mutz, Marc marc at kdab.com
Thu Jun 6 10:42:04 CEST 2019

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 

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 

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


More information about the Development mailing list