[Development] Use of Standard Library containers in Qt source code

Sergio Martins iamsergio at gmail.com
Sat Jul 2 14:11:32 CEST 2016


On Friday, 1 July 2016 11:36:56 WEST Thiago Macieira wrote:
> Premises not under discussion:
> 
> 	Qt source code is product and meant to be read by our users
> 	Qt source code must be clean and readable
> The above is not up for debate.
> 
> For some time now, we've had a flurry of changes to Qt source code that uses
> the Standard Library's containers and algorithms, in the name of
> performance and often code size gains.

and in some cases better readability too. For example, whenever you use 
cbegin, cfind, push_back you're writing code that's not only understandable by 
Qt developers but also C++ developers.

Lowering the bar for C++ developers to start contributing is important.
I agree that STL also has many examples of worse readability, like very 
verbose algorithms. We should tackle this on a case by case basis.

> 
> I'm not disputing that there is a gain. But I am wondering about the
> trade-off we're making with regards to readability. For example, I was just
> reviewing this code:
> 
>     if (d->currentReadChannel >= d->readHeaders.size()
> 
>         || d->readHeaders[d->currentReadChannel].empty()) {
> 
>         Q_ASSERT(d->buffer.isEmpty());
> 

"empty" is evil, I've fixed many places where the developer meant "clear()":

https://quickgit.kde.org/?
p=kdelibs4support.git&a=commit&h=c27b851e62307dd16780bf94aff8e6c650ac8dc7

I think we should even remove QList::empty() in Qt6, we want STL compat with 
the good things, not the bad things.

> What do we do?

What do we do to fix what ? First state the problem.
You made a case against "empty" and then extrapolated to STL, as if you had a 
3rd premise "STL is always less readable".

> 	empty		->	isEmpty

Agreed, it's error prone.

> 	push_back	->	append
> 	front		-> 	first
> 	pop_front	->	takeFirst
> 	cbegin		->	constBegin
> 	cfind		->	constFind

Disagreed, the later form is the common denominator between C++ and Qt 
developers.


Regards,
Sérgio Martins



More information about the Development mailing list