On Mon, May 20, 2019 at 08:44:47PM +0000, Marco Bubke wrote: > On May 20, 2019 22:16:11 André Pönitz <apoen...@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' _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development