[Interest] move methods in QList

Thu Oct 12 01:49:24 CEST 2017

Elvis,

Here are some pearls of wisdom (or freshly polished t...s) depending on 
your opinion of them and myself. It is some rules of thumb I've 
developed over the past 30+ years in IT on numerous platforms with 
countless tool sets.

1) If you cannot immerse yourself completely in it and still solve the 
problem, it's the wrong tool set for the job.

If you are trying to use Java for something (heaven forbid!) and have to 
keep dropping to JNI, red flag, you're using the wrong tool. If you are 
using Qt and need to keep using new C++/STL containers, red flag, you 
are using the wrong tool.

That rule of thumb has served me well from Pro-C application generator 
to Cscape to Cognos PowerHouse to Clipper to Zinc (ZAF) to Java to soooo 
many other things. It doesn't require any white smocked palms skyward 
chanting to find enlightenment.

2) If "the data" has any real value, you always need some kind of index 
to it.

This means I typically shun QList, QVector and QHash. Why shun QHash? 
Because hashes allow for collision which usually indicates a rather poor 
choice of key value. Yes, I try to completely ignore that part of QMap 
which allows for multiples of the same key. Bad bad bad bad bad thing 
that was. Yes, I still use a queue or a stack when the situation calls 
for it and yes, if the Qt thing I'm feeding needs a list I will create 
one, but, honestly, I stuff things into a QMap or SQLite database.

I see too many projects declaring a struct  or data only class because 
the data is "somehow related." More and more keeps getting added to the 
structure. Then they try to stuff it into a list/vector then they start 
needing it in different orders based on different criteria. Had they 
done the right thing and stuffed that into a table, they could easily 
view the data however they wanted. FAR too many people take OOP too 
seriously. This "the object is everything" approach to systems design is 
tragic. Most of the data people try to wedge into custom objects really 
needs to be a row in a table you select as needed. If your row ends up 
with too much unrelated junk you can make another table. The bulk of the 
application will not care what SELECT statements is executed.

I guess I'm answering (in a round about way) the last question of your 
post as well.

If someone is worried about the efficiency of a Qt container they are 
either coding for an underpowered battery operated embedded target _or_ 
they are doing data wrong. I have developed for "that target" which 
didn't even have a GPU so we had to preload all of our images and blit 
them as necessary with Qt. The hardware choices were deliberate because 
product was shooting for something like 10 days of operational battery 
life (not standby).

I have also walked onto projects where they kept throwing faster and 
faster processors at the grid powered embedded system and pushed it to 
4Gig of RAM because every piece of data was an object and it all had to 
be in RAM. The long term storage was a rash of JSON files with a cryptic 
directory naming structure. The developer(s) which had been sent to 
Digia for Qt training came back all enamored with QML (puke) and JSON 
files so that _must_ be how data acquisition is done. Suffice it to say, 
when I got rid of the bulk of the JSON files, replacing them with an 
SQLite database and a series of tables our CPU and RAM consumption 
dropped dramatically. The application was quicker and more stable.

How does that answer your question? In memory containers are meant to be 
temporary and no, temporary is not the life of the application. If data 
is actually needed for that length of time it needs to be on some form 
of semi-permanent media, not a container class.

Are there exceptions to that rule? Damned few. One project had a giant 
QHash which was the target of a message queue publish-subscribe service 
routing COOA objects. It had to exist for the life of the application so 
each unique COOA had a unique reception point, but each message only 
existed until the next of its type came in. It was basically a transient 
data parking lot with assigned parking.

On 10/11/2017 03:36 PM, interest-request at qt-project.org wrote:
> Sorry for jumping in here.
>
> I've recently been reading back on some of the threads on the
> disadvantages of QList, especially the thread right before the time
> when the QList docs were updated to no longer suggest it as the
> "go-to" Qt container. I've also looked through Guiseppes slides, and
> reading other discussions here and there.
>
> And I'm still confused. I'd like to do the right thing, but right now
> I'm unsure if that is:
>
> - Use std containers as much as possible (i.e. always except if I need
> to interface with Qt APIs)
> - Use Qt containers, but pick QVector over QList whenever possible
> (your suggestion)
> - Use QList, it's not that bad after all, and has good worst-time for
> many operations
>
> There seem to be differing opinions even among Qt heavyweights on how
> strongly QList use should be discouraged, and even on how strongly (if
> at all) Qt container use should be discouraged.
>
> I know the difference between QVector and QList, and the quirks of
> QList (not least of all because it's been discussed a lot), so I guess
> the best thing I can do is form an opinion of my own, and stick to
> that.
>
> But.. one thing I don't like about the advices like "Use X ... except
> if you possibly intend to interface with the Qt API" (where X is
> QVector, or maybe std::vector depending on your stance) is that
> sometimes you simply don't know that up-front. Also, it gives a sort
> of Frankenstein appearance to the code, where it's not clear to a
> casual reader why one type of container was picked over the other.
>
> Could others chime in here. If you were to start a project today, what
> focus would you have wrt to containers? Would you do your utmost to
> stay with std containers? Strive to use Qt containers, but avoid QList
> as much as possible? Or even not be afraid of QList use at all, for
> the convenience of being able to pass it to some Qt API later on?
>
> Another thing for you Qt devs: Qt's APIs are littered with QList.
> Guiseppe mention in his slides that it's out of the question to change
> that for Qt 6, because it would be such a big API break. But, when
> should such a change be made, if not during a major version bump?
> There's nothing more major than that. The only more careful approach I
> can think of is deprecation over a full major cycle, only to be
> changed in the next. Or are we going to live with a Qt API that
> interfaces using a discouraged container forever?
>
> Elvis

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
http://lesedi.us/
http://onedollarcontentstore.com