Why use QVector(Qt) instead of std::vector
C++QtVectorC++ Problem Overview
I'm very new to C++ and Qt, but I'm very good at C#/Java.
The point is I like cross-platform, but I'm confuse with Qt. Isn't std::vector already cross-platform, doesn't Qt provide an equivalent to a non-crossplatform thing?
Also how are File and QFile different?
A link would be nice, thanks :)
C++ Solutions
Solution 1 - C++
This article loooks good. It compares Qt Template Library with Standard Template Library:
Hope, you'll find it interesting seeing all the differences listed there in the article.
EDIT:
Here is what I find interesting:
> My opinion is that the biggest > advantage of the QTL is that it has > the same implementation (including > binary compatibility) on all OSes > supported by Qt. Some STL > implementations might be below par > when it comes to performance or they > might be missing functionality. Some > platforms don’t even have an STL! On > the other hand, the STL is more > customizable and is available in its > entirety in header files… Like I said, > there is no clear winner.
Like he said, no clear winner. But still reading the article makes lots of things clear. Its better to know the difference than going for one, without knowing the other.
Solution 2 - C++
The QVector class is reference counted and is geared to being shared without copying. Qt provides a lot of containers that correspond to STL containers. A document that describes these with some explanation of the internals and a bit of rationale:
Solution 3 - C++
From over here:
> Qt originates from a time when C++ and > the standard library were not > standardized or well supported by > compilers. It therefore duplicates a > lot of stuff that is now in the > standard library, such as containers > and type information. Most > significantly, they modified the C++ > language to provide signals, so that > Qt classes can not be used easily with > non-Qt classes.
Solution 4 - C++
The bad experience I've had with QTL was related to QTL not raising any exceptions; this makes it harder to trace and fix critical errors. Also, STL implementations are closely related to a compiler, because parts of the library require compiler-specific extensions to the language. This means a STL implementation can often outperform QTL, which needs to be portable and therefore cannot benefit from said extensions. The debugging issue was critical for me though.
Solution 5 - C++
Since no answer mentioned it, Qt containers, including QVector generally have a fuller API, which does enable a certain amount of extra convenience and reduces verbosity when compared to std::vector.
QVector isn't really integrated into the Qt APIs, that role is taken by misfit QList, so it is not really a strong argument to use QVector for overall better compatibility with Qt APIs. Note that this might change for Qt 6, as the shortcomings of QList become more and more acknowledged.
That being said, if you already depend on Qt for your application, it would make good sense to use QVector for the convenience. I presume that nobody is going to add such a bloated dependency as Qt just for a container or two. QVector is efficient and a solid performer, and will run without problems on any platform, supported by Qt.
On the other hand, if you want to make a core logic API that is framework agnostic, it would be a good idea to develop it in standard C++ if possible, so you get something portable that isn't tied to a particular GUI framework so you can easily migrate it to a different one in the future if you need to.
Solution 6 - C++
C++'s std::vector is cross-platform because it is part of the C++ Standard. Every C++-conformant compiler must provide it.
I'm not familiar with Qt, but I did see this in the docs:
> Note: All functions in this class are > reentrant.
It's also likely (speculation) that the QVector class is more easily integrated to hold Qt-centric objects than std::vector might be. Again, I'm not familiar with Qt so you have to decide for yourself.
As a rule of thumb (to which there are many exceptions), I would tend to use std::vector unless I had a compelling reason to use some library-specific container class.