View Full Version : About STL containers and QT equivalent

11th February 2011, 09:41
In both cases, I would like to view a perfomance comparison between containers, with some examples: list > bla bla bla, vector > bla bla bla, etc.
First I'd like to view a general comparison, later a comparison with QT equivalents.
Can anyone give me some link?

11th February 2011, 11:03
Performance comparisons in what situations? Insert, lookup, deletion and in the beginning, middle or end of the container? You have to be more specific. If you expected a single sentence stating that std::list is faster than std::vector then you won't get such a "benchmark". Besides you can always write your own.

11th February 2011, 12:08
I simply am looking for an article that talk about the theme.
What container is recomended for.... what can I expect from every type, etc.
And finally a question about QT containers, are better than STL?
Thanks Wy

11th February 2011, 12:21
And finally a question about QT containers, are better that STL?
Is a hammer better than a screwdriver?

In the STL documentation for each class, they explain for each container, what kind of algorithm it uses, and for which kind of task it is optimized.
so a vector is better than a list for some things, and vice versa for others.
The Qt container classes documentation explains in what way the Qt containers are different, and when they should be preferred.

11th February 2011, 13:12
I stick to Qt containers when i am coding in Qt. Many functions in Qt return/expect a QList and it is a waste of time converting between STL and Qt. Finally the implicit sharing means i dont have to allocate everything on heap ( for example returning a locally created list).

11th February 2011, 13:13
There is also this:
and this:

But none of these will answer a question what is "better" than something else.

11th February 2011, 15:01
I only want to learn.
Sun people have a good article about it (in Java app), but I dont think I can extrapolate the information to c++, isn't it.

11th February 2011, 15:17
No,, you can't.