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

Thiago Macieira thiago.macieira at intel.com
Mon Jul 4 22:01:55 CEST 2016

On segunda-feira, 4 de julho de 2016 09:59:44 PDT Christian Kandeler wrote:
> > 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 must admit I don't see a problem here. We are not talking about some 
> random third-party library that people are pulling in gratuitously, but 
> about the Standard Library, an integral part of C++ that every developer 
> should be at least generally familiar with.

Of course, I was able to reason what it was after looking up the definition of 
the variable in question. It didn't cost me more than 60 seconds to do this, 
between the wondering "wtf is he doing", forming a hypothesis, proving it, 
then navigating back and then restoring my frame of mind.

The problem is that I do more than one review a day. I would be surprised if 
there are more than 5 people who do more reviews than I do. And I spend less 
than 10% of my week on Qt, so it's important for me and for those whose 
changes I review that I be efficient.

In this particular case, the fact of using a QVector of std::deques completely 
threw me off and I didn't understand the author's intention at all. I had to 
stop the review, which led to this email.

> Having said that, I personally follow the "use Qt types by default" 
> approach, but should we really regard STL containers as dangerous 
> intruders that need to be kept out if at all possible?

No, I agree we should allow them when there's a clear benefit. Qt has no 
equivalent for std::deque and I do think our time is best spent in other 
things than reimplementing one. That is the status quo and Option 4 in my 

But I am thinking of Option 3: use the Standard Library containers (cake) and 
still have our API (eat it too).

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list