# [Development] Views

André Pönitz apoenitz at t-online.de
Mon May 20 23:11:26 CEST 2019

On Mon, May 20, 2019 at 08:44:47PM +0000, Marco Bubke wrote:
> On May 20, 2019 22:16:11 André Pönitz <apoenitz at t-online.de> wrote:
>
> > On Fri, May 17, 2019 at 10:17:10AM +0200, Mutz, Marc via Development wrote:
> >> [...] There is no readability difference between the use of a Qt container and
> >> that of an STL container.
> >
> > Exhibit A:
> >
> >     foo().contains(x)
> >
> >
> > Exhibit B:
> >
> >     {
> >         ... container = foo();
> >         std::find(container.begin(), container.end(), x) != container.end();
> >     }
>
> AFAIK contains is now part of the STL.

Define "now"...

> But to show a pattern I see often with Qt container is the use of contains and
> then access the element with a key again. I that case the STL with iterators
> leads you to better performing code. Ranges hopefully make much of this code
> even more readable and performant.

Performance is always a combination of "raw run-time performance" and "time to
market".

There's no point in saving 30 processor cycles a day, even for a million users,
if that takes one hour of developer time to implement in a desktop application.

People who disagree wouldn't ever touch Java or JS or any interpreted language.
Or std::ostream for that matter.

You know as well as I do that e.g. QList is heavily used in e.g. the Qt Creator
code base, and that this is absolutely *no* performance problem. Sure, it's not
used in *really* time-critical parts, but for the 100%-\epsilon non-exceptional
stuff it's just "good enough".

Andre'