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

[Thiago Macieira]

On sábado, 2 de julho de 2016 13:11:32 PDT Sergio Martins wrote:
> 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.

See also my reply to Stephen on the same topic.

I agree with the logic, but I have to question the effort vs benefit.

This is the same question as with our CLA: how many developers are we turning 
away because of the issue? How many would make meaningful contributions if 
only the situation were different? You can extend this to other minor issues, 
like coding style (use of spaces instead of tabs) or even buildsystems ("I 
won't touch qmake").

I honestly do not see a horde of developers stopped at the gates of the API. I 
really don't think that's the case, as most of the developers willing to make 
contributions have usually used Qt and are somewhat familiar with our API. 
That is, the contributors usually are users of Qt that move upstream.

There are a few exceptions of developers moving downstream. For example, 
Wayland developers that come take a look at our code. How do we cater for both 
low-level C coders and for algorithms-using C++ coders?

> > 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()":

Yeah, except that here it *wasn't* clear(). It was "size() == 0" (isEmpty).

But I had to check.

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

The situation (not everyone will agree there is a problem) is what I said at 
the beginning of my email and left quoted here: there's a flurry of new code 
using the Standard Library containers and algorithms. Do we do something about 
it?

Note that option 1 is status quo.

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

You mean the former, not latter.

Indeed, but my whole argument is that developers writing Qt code and, more 
importantly, those *reading* Qt code, are more familiar with the latter cases.

If the problem is only "empty", we can get around the problem by requiring 
"size() == 0" instead.

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