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

[Thiago Macieira]

On sábado, 2 de julho de 2016 08:42:42 PDT Marc Mutz wrote:
> This sort of sentiment fosters mistakes such as looping over
> QVector::erase(it), turning a linear operation quadratic, and people trying
> to reimplement binary search, leading to unstable search results that
> depend on the size of the container. IOW: bugs.
> 
> Yes. I'm saying: Less STL use == more bugs.

Which is why I grudgingly accept std::erase + std::remove_if, despite being 
ugly-to-read code.

> We should instead foster the use of STL algorithms ("No raw loops"), not use
> ignorance of the greatest C++ library ever written as a reason not to use
> what it has to offer.

If there's no difference in performance, I prefer the raw loop.

> About APIs:
> 
> The STL has a great API. push_back() / back() vs. append() / last(), e.g. It
> just happens to be largely consistent with itself instead of with Qt. But
> camelCase is not intrinsically "better" than underscored_names, and I also
> fail to see why first() should be intrinsically superior to front().

Intrinsically, neither is superior to the other. But that was not my point.

My point is that inside Qt, Qt API is more readable than the Standard Library 
API because one is consistent with the rest of the code, the other isn't.

> And as an aside: please stop claiming that "the Qt API was there before the
> STL one".

I claimed that Qt had its API published before the C++ standard was out. I 
know that SGI had published STL before the standard.

> Tell the world how the Qt containers looked when the STL was released. Go
> on. If you want Qtsy containers, go back _there_. The current Qt containers
> are more STLsy than Qtsy, and they're better for it.

The API style is pretty much the same and this is my only point here: API and 
consistency.

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