Using QObjects vs Normal C++ objects

[jkwok678]

Is there any reason to favour things like QString or QVector or other QVariants of data strucutures over the normal C++ counterparts? What's the differences?

[VRonin]

QString handles encoding better than std::string, for the rest of the containers, the std:: ones are usually slightly more efficient (because compilers optimise them to the extreme) but Q versions of the containes have a much better interface with loads more functionality baked in that you don't have to program manually. It's a tradeoff of programming convenience for a bit of performance.

[mrjj]

Hi
Also some Qt classes use implicit sharing.
https://doc.qt.io/qt-5/implicit-sharing.html

[jkwok678]

@mrjj
Hi, thanks for the link.
In the link you sent me it says

"The benefit of sharing is that a program does not need to duplicate data unnecessarily, which results in lower memory use and less copying of data."

and also

" Many C++ classes in Qt use implicit data sharing to maximize resource usage and minimize copying. "

So does this mean that when compared to std library, Q alternatives are faster/slower or uses less or more memory?

[mrjj]

@jkwok678 said in Using QObjects vs Normal C++ objects:

So does this mean that when compared to std library, Q alternatives are faster/slower or uses less or more memory?

Generally speaking: slower but less mem, in theory - but std also have some tricks like std::move and others so a good coder like VRonin could make std run as fast/efficient or more vs the Qt versions. Also after c++ 11, they added some tricks to the language itself so it really depends on the programmer and
how the containers/objects are used.

So its mostly convenience as you get copy-on-write( implicit sharing) directly out of the box with no extra effort from the programmer.

Also Qt offers nice things like streamable with QDataStream so
a QList with Qt objects in it can directly save and load itself.

Also in older times, the STD across compilers was not unified and could have
different implementations details where Qt's would work the same across compilers. Its why it has its own in the first place.

So we can't just say Qts better or STD is better as they both have advantages and disadvantages.

Also, the speed difference is often so insignificant that it won't be the difference between your app seems fast or not.

So say if the Qt container is not fast enough for a given use case, then replacing it with the same type of STD container will not make suddenly fly.
Or reverse. (unless all you needed was implicit sharing:)

So what to use ?

We use Qts version unless the interface is to be used with non Qt
code. The Qt containers are smoothly integrated with the rest of Qt so
there are quite many benefits not related to memory and performance.

[SimonSchroeder]

Nine years ago I did some optimization on my software which used a huge vector of data (profiling showed that most of my time was spent in one function of std::vector). This was on Linux using GCC (I assume that was version 3 or something). Back then, replacing std::vector for QVector gave a performance boost of 3x. This was mostly an implementation issue as my call of a single function in std::vector internally triggered ~5 more function calls internally. And this was inside a loop.

So, at least it used to be that Qt was faster than the STL (in certain applications). Implicit sharing might slow down any writes as these need to check for sharing atomically (should be marginal). Though it certainly used to be faster when copying a vector, but never changing it (as the data is never actually copied). Move-semantics in C++11 certainly mitigates this advantage of Qt in many use cases.

Certainly, I would not rely on the STL to be fast. There is a reason why EA wrote their own STL a while a go. Especially Microsoft's STL can be really slow in debug mode.

In general, I use Qt's data types inside my Qt code. If I have code to be used outside of my GUI applications (in some command line application), only then do I use STL versions. Especially, QString has more useful functionality over STL strings (e.g. trimmed()) – not to mention QStringList (no equivalent in STL). As long as you already have Qt in your application and you don't hit a performance problem I suggest using Qt, otherwise use STL. If you think about performance, there is no other way than to benchmark your application and check if a switch from Qt to STL really makes a difference.

[Bonnie]

If I'm using STL, it is probably because I need emplace.