>No-one, not even experts understand QList, really. So it may appear to be easy >to use, but is actually a container only absolute experst should use.
Marc, you are still conflating optimal runtime efficiency with algorithmic correctness. QList is easy to use correctly in algorithms. It is almost hard to make a mistake. That is all "easy to use" means. It doesn't mean "easy to use while achieving optimal runtime efficiency." You can't judge all programmers using your encyclopaedic knowledge as the standard. There is a lot to be learned by doing things correctly the easy way. It even makes learning to do the same things with optimal runtime efficiency more meaningful. martin ________________________________________ From: Development <development-boun...@qt-project.org> on behalf of Marc Mutz <marc.m...@kdab.com> Sent: Tuesday, January 19, 2016 11:52 AM To: development@qt-project.org Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote: > On 15/01/16 23:20, "Development on behalf of Thiago Macieira" <development- boun...@qt-project.org on behalf of thiago.macie...@intel.com> wrote: > >On Friday 15 January 2016 18:42:43 Marc Mutz wrote: > >> And you will see it over and over again until enough people are fixing > >> premature pessimisations in existing Qt code. There's a notable increase > >> already. But it takes a long time to turn a supertanker around... > > > >Some of us call them "trade-offs". Every trade-off is a pessimisation > >somewhere for an optimisation somewhere else. Often, they're not measured > >in the same units or not quantifiable at all. > > > >API quality and consistency fall under those definitions. > > Exactly this. > > >> And no, I cannot believe that using the Qt containers leads to faster > >> applications. It may lead to applications faster, but not to faster > >> applications. > > > >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 > >rule). > > And this. Let’s not forget to ask ourselves the question why many > developers use Qt in C++ development, often even in the case where they > don’t need a UI. For the past 20 years a lot of our focus has been on > making development easy, and creating APIs that serve that goal. This > means that we are in many case optimising for TTM more than for ultimate > speed. > > I think we agree that std containers are in many cases faster than the Qt > containers. But they are harder to use and especially developers that come > from other languages often appreciate the ease of use of the Qt > containers. I always cringe when I hear this. What, specifically, do you mean by "easier to use"? No-one, not even experts understand QList, really. So it may appear to be easy to use, but is actually a container only absolute experst should use. And a QVector provides exactly the same guarantees as a std::vector. How come one is easier to use than the other? Because QVector has indexOf()? And what about those cases where the user wants to find an element by just a field? They will write for loops, most likely, and not use algorithms. The crucial point here is that there's no "better" Qt API for this than what exists on std::vector. Instead, there's a much more complicated API by sheer volume and duplication, without being near extensive enough for even very simple tasks. At some point, the question must be asked whether CoW and append() vs. push_back() do not become more of a burden than a merit. And whether we need three names for size(). > The main question IMO is how we can bring these two worlds closer together > for Qt 6 (or maybe even to some extent in Qt 5.x). My answer would be to use std containers exclusively, and write a wagonload full of Qt-level docs about them, ie. integrate them into the Qt docs. Thanks, Marc -- Marc Mutz <marc.m...@kdab.com> | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development