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

[Stephen Kelly]

Thiago Macieira wrote:

> On sábado, 2 de julho de 2016 12:40:53 PDT Stephen Kelly wrote:
>> So, by sticking to lots of raw loops, you're actually actively excluding
>> other parts of the C++ community from participating. I don't have numbers
>> to  qualify it, but there seems to me to be a much larger community
>> following modern C++ practices than following Qt practices on questions
>> like this.
> 
> The converse is also true

I agree, and I encourage you to raise std::empty as a problem

 http://en.cppreference.com/w/cpp/iterator/empty

so that it can be renamed to is_empty.  C++ developers should get 'is' in 
the name if that is the correct thing to do (ignore the camelCase/snake_case 
difference - that is orthogonal to the 'is' issue).

Giving that feedback that such a method must have 'is' in the name would be 
a valuable contribution from Qt experiences to the C++ community and work 
towards bridging the divide that I claimed exists (in both directions). 

> : by using auxiliary functions to do things where
> a simple loop would do, you're excluding a sizeable community that has
> never encountered those functions. Especially if those auxiliary types and
> functions have different and sometimes bewildering names, different from
> Qt's.

You can make Qt names for things. The important thing is that there is a 
name. Why don't we write 

 std::begin(container) == std::end(container)

everywhere? Because we named that concept 'emptiness'.

Consider this caricature of the kind of code that exists throughout Qt:

 int index = someFunctionParameter;
 int foo = containerOfIndexes.size();
 if (something) {
    while (anotherThing) {
      if (foo % 2 == 0) {
        ++foo;
        ++index;
      }
    }
 } else {
   ++foo;
 }

 while (foo) {
   if (bar && bang) {
     if (bang) {
       for (int i = 0, e = containerOfIndexes.size(); i != e; ++i) {
         if (index < containerOfIndexes[i]) {
           index = containerOfIndexes[i];
         }
       }
     }
     if (index < 0)
       break;
   }
 }

 return index;


It is not possible to reason about code like that. I have the feeling that 
faced with code like that, people just don't attempt to reason about it 
while at the same time trying to get on with what they are trying to do.

Here's a recent example of a contributor responding exactly that way to such 
code:

 https://codereview.qt-project.org/#/c/161133

The way to deal with functions like that is to extract loops and other 
concepts into functions with names. Delegating things like that has the 
effect of making the function shorter. Adding comments instead would not 
have a positive effect on the size of the function and good names are less 
likely to bitrot than comments.

In the above example you would start by extracting a qMaxValue function. You 
could implement that function in terms of std::max_element, or you could 
write a loop in the function if that's more comfortable. Even in the latter 
case, it is not a 'raw loop'. You have named a concept and using it will 
make other code more readable.

> Like you, I don't have numbers. But I can tell you one thing for sure:
> that community that follows non-Qt practices is not here.

I don't think that's true. People who do follow modern practices or boost do 
sometimes appear on this mailing list (and more than that read it - hello 
lurkers!). They don't tend to become long-term contributors though.

> It would be nice
> to attract them, but not at the expense of losing the people we already
> have and are familiar with Qt internals.

I think starting small to introduce the concepts and with Qt names like 
qMaxValue would work. Yes, learning and change would need to happen, but 
that can happen at whatever pace you choose. 

I'm not going to recommend replacing all loops with some Qt version of range 
adaptors starting tomorrow. 

There are many small steps which have benefits for readability.

>> I encourage you and everyone else to dive into it.
> 
> No, thanks.

I expect that, but I continue to encourage it (to everyone) anyway :).

Thanks,

Steve.