Why use QVector(Qt) instead of std::vector

Question

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 :)

Adaurd

There is also no File which compares at all to QFile. FILE* is something entirely different. – Crumley

Qt is old, and provides components that, once upon a time, were not available on all compilers. There is not much use for those in new code. – Cheesewood

To add to @Bo Persson's answer: the Qt containers aren't even 64-bit clean. They use int for sizes, so they can never store more than 2^31 elements on x86-64. – Shaman

I only use the Qt containers if I have a to call a function that accepts only a Qt container. – Eosinophil

larsmans but what about this? from Qt documentations: typedef qint64 Typedef for long long int (__int64 on Windows). This type is guaranteed to be 64-bit on all platforms supported by Qt. Literals of this type can be created using the Q_INT64_C() macro: qint64 value = Q_INT64_C(932838457459459); – Hammett

@shbk: doesn't matter as long as the class' methods/ivars are defined using int you won't gain any 64bit benefits by simply passing a true 64bit value to it as they get lost in the first implicit cast it passes. – Threescore

Answer 1

This article loooks good. It compares Qt Template Library with Standard Template Library:

• QTL vs STL

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.

Astrakhan

By the same viewpoint Qt may be sub-par and missing functionality. And what is binary compatibility of a template container? – Eosinophil

Binary compatibility is important for linking to libraries built with different toolchains. This bit us last year... the vendor ended up switching to C-style arrays from std::vector. (Yes, I know this is an old thread...) – Brinkley

Might someone update this thread? I mean it's been a while since this answer was posted. What about C++11 and C++14, have they brought anything new to the STL's? Isn't C++ now striving to be crossplatform? Just my own curiosity. – Wrote

@Paul-SebastianManole: C++ was crossplatform from its very beginning. – Astrakhan

Sorry, I meant the STL. – Wrote

@Paul-SebastianManole: Even STL was crossplatform from its very beginning. – Astrakhan

OK so why does Qt still use its own implementations of STL provided structures? – Wrote

@Paul-SebastianManole: Short answer : consistency. For long answer, google it. – Astrakhan

IMO, as time goes on, due to massive improvements in the STL, it makes less and less sense to use Qt's container classes unless needed for compatibility. – Site

@Nawaz seems that "QTL vs STL" link is no longer working. – Wohlert

Answer 2

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:

• Inside the Qt 4 Containers

Kesley

Answer 3

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.

Chalcopyrite

This is not the whole story and gives a wrong impression. There are still reasons to use Qt containers, not the least being shared memory and the like. But if you're not using anything else Qt, don't use them. – Crumley

I don't know if a gtkmm FAQ is the best source for Qt information... At least the part saying that Qt modified C++ language is not true. – Indissoluble

@Roku : How else would you describe the MOC? – Fess

C++ language leaved untouched – Hammett

The moc is a preprocessor for C++, so as to support their meta objects. It compiles Q_OBJECT and other meta object macros, to C++. They thus extended C++; just as C++ is an extension of "C". You don't usually need to know them, and just code straight C++. – Doggett

I'm not quite familiar with Qt, but I fail to see how the use of preprocessor macros can "modify the C++" language". Besides, currently, C++ theorists agree that the C preprocessor shouldn't be used in C++, but many established C++ libraries (MFC, WxWidgets, Boost and Qt) make heavy use of the preprocessor. – Besom

Answer 4

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.

Qt 6 update: Now QList and QVector are pretty much functionally identical.

Aloisia

Answer 5

I compare Vector and Qvector by this code the vector mush faster than Qvector. both code implemented in Qtcreator and compiled with visual studio 2019 compiler

void qvectortest()
{
    QVector<double> s[10][100];
        for (int is = 0; is < 100000; is++)
        {


        for (int i = 0; i < 10; i++)
        {
            for (int j = 0; j < 100; j++)
            {
                for (int k = 0; k < 10000; k++)
                {
                    s[i][j].push_back(k);
                }
            }
        };
        QVector<double> d;
        d=s[0][0].mid(0);
        d.clear();
        for (int i = 0; i < 10; i++)
        {
            for (int j = 0; j < 100; j++)
            {

                s[i][j].clear();

            };
        };
        cout << "Qvector="<<is << endl;
        }
}

and

void vectortest()
{
    vector<double> s[10][100];
        for (int is = 0; is < 100000; is++)
        {


        for (int i = 0; i < 10; i++)
        {
            for (int j = 0; j < 100; j++)
            {
                for (int k = 0; k < 10000; k++)
                {
                    s[i][j].push_back(k);
                }
            }
        };
        vector<double> d;
        d.assign(s[0][0].begin(), s[0][0].end());
        d.clear();
        for (int i = 0; i < 10; i++)
        {
            for (int j = 0; j < 100; j++)
            {

                s[i][j].clear();

            };
        };
        cout << "vector="<<is << endl;
        }
}

copmare operation/Time figure

Ducks

Answer 6

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.

Yester

Answer 7

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.

Ideology

reentrant doesn't have any relations to what you mean. Reentrant means that any thread can call a member function on an instance of reentrant class while no other class call a member function of the same class – Hammett

@AlexShulzhenko: Agree about reentrant vs thread-safe. All reentrant means here is that the internal data store (array) is private and may only be accessed and manipulated via class methods. Ref: doc.qt.io/qt-5/threads-reentrancy.html#reentrant – Circumscription

As a general rule this holds true, but Qt is not a library, it is a framework and if you first are using a framework, it makes sense to go all in. – Jenjena