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

Solution 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.

Solution 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

Solution 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.

Solution 4

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

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.

View more solutions

Comments

[rubenvb]

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.

[Admin]

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.

[ildjarn]

@Roku : How else would you describe the MOC?

[edA-qa mort-ora-y]

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

[Tebe]

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

[Tebe]

C++ language leaved untouched

[darron]

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

[kevinarpe]

@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

[Paul-Sebastian]

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.

[Nawaz]

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

[Paul-Sebastian]

Sorry, I meant the STL.

[Nawaz]

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

[Paul-Sebastian]

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

[Nawaz]

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

[minexew]

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.

[Vincas Dargis]

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