[Development] Use of Standard Library containers in Qt source code
Thiago Macieira
thiago.macieira at intel.com
Fri Jul 1 20:36:56 CEST 2016
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.
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());
The use of the Standard Library member "empty" is highly confusing at first
sight because it does not follow the Qt naming guidelines. It's even more
confusing because the next line has "isEmpty". When I read this code, I had to
wonder if that "empty" was a verb in the imperative, meaning the author was
trying to remove all elements from the container.
I had to look up the definition of readHeaders in the review and note that it
was a std::deque, not a Qt container.
What do we do?
Option 1:
Not use Standard Library containers, just use the Qt containers as they exist.
Option 2:
Create new Qt containers to have the same complexity as Standard Library
containers, but following the Qt naming conventions. Possibly with implicit
sharing.
Option 3:
Create Qt API wrappers for those containers like std::deque, adding only a few
inline functions to match the Qt-style API where the Standard Library API
deviates. Examples are:
empty -> isEmpty
push_back -> append
front -> first
pop_front -> takeFirst
cbegin -> constBegin
cfind -> constFind
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list