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-requ...@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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
