[Development] Question about QCoreApplicationData::*_libpaths

[Marc Mutz]

Hi Bo,

On Friday 15 January 2016 12:40:05 Bo Thorsen wrote:
> We have seen this rant from you several times before.

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...

On Friday 15 January 2016 12:40:05 Bo Thorsen wrote:
> Maybe I have a different focus, but I just don't see the need for raw 
> speed very often. On embedded applications I'm very sensitive to it, of 
> course. But on the Windows desktop, I have yet to see an application 
> where the choice of QVector or std::vector makes any kind of difference 
> to the user.

This is the old difference: you think using std::vector is premature 
optimisation and I think that using QVector is premature pessimisation.

Qt is still a C++ library. If it wasn't for the need for bare-metal speed, 
everyone would use Java instead. It's safer, more coherent, programmer 
productivity is higher and programmer cost is lower.

But safe languages just don't cut it anymore, that's why C++ is still alive.

But if a seemingly innocuous piece of code like

   for (const auto &e : qtContainer)
   funReturningQtContainer().first();
   ...

leads to a memory allocations, nay, a complete deep copy of the container, 
then this is simply *not acceptable* in C++. I wouldn't even be acceptable *in 
Java*. It's *orders of magnitude* slower than how an STL container would 
behave. Sure, if this is not a hot code path, you won't notice. But these 
things add up. There's a reason why we can't do much more now with the 
supercomputers that we have on our laps than we could do in the 90s on 
workstations. Compiling Qt, e.g. hasn't gotten any faster between Qt 1.x and 
5.x...

But I repeat myself...

> Sure, they are there. And there are areas in the model of an application 
> where we should consider speed always. But for the vast majority of the 
> lines of code I write, it makes no difference at all. If it doesn't make 
> a codewise difference, then obviously a faster framework class is better.

And why would you advocate learning *two* classes that do exactly the same 
thing if you need the fast one anyway (for when speed matters)? That surely 
isn't good API design.

> However, my customers have developers that are a lot less experienced 
> than us. And it's my observation that using the Qt classes over the std 
> classes lead to fewer mistakes and faster applications. It seems much 
> easier to shoot yourself in the foot with std. I don't know why this is, 
> it's only what I observe when I look at code written by others.

I don't buy that argument that the STL is less safe. You should teach your 
customers their STL debug mode. They will never look back at the Qt 
containers.

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.

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts