Qt smart pointers vs STL smart pointers

[aliks-os]

I just have started to use smart pointers in my applications and a little bit confused: what type of smart pointers better to use in developing Qt or STL ?

During the last period, some elements of Qt are marked as obsolete and recomended to use its stl analoge, for example:
foreach -> for range
qSort -> std::sort (Members for QtAlgorithms).

Is a possible situation when someday the Qt smart pointers will announced as obsolete ? And will be recomendation to use stl smart pointers...:)

[koahnig]

@aliks-os

Nothing is chisled in stone and may change epecially i the world of software.

In my opinion the first shall be with what you fill more comfortable?
That should probably have the highest priority for you.

For myself I am not using pure Qt. It is in most cases a mix of the worlds of Qt, stl and boost. For the latter one my rational is that it will become stl and therefore there should be no problem. This I cannot underline anymore, since shared_ptr became part of stl. At least my rational at the moment that they will work the same way, I do not dare to change them swiftly from boost to stl.

Personally I am continuing to use containers and string from stl. This makes it a bit awkward when working with Qt gui and you end end up with some mix.

[aliks-os]

@koahnig
Many thanks for your opinion.

I read some debate on this subject, and some expressed that "if you started using Qt in the project, you should use Qt containers, smart pointers, etc as much as possible in the project. And better not mix Qt and STL"

and I would like to know about this experience with the use of more experienced professionals than I

[kshegunov]

It would very much depend on what you want to do. I, for one, stick to Qt's QSharedDataPointer and QExplicitlySharedDataPointer. Aside from those two I rarely touch any other smart pointer machinery. I dislike the STL API so even if I decide I need something more exotic I stick to Qt's implementations. Probably the notable exception is QPointer which has no STL equivalent to begin with, as it provides a guarded pointer to QObject instances, which is Qt specific. There's nothing wrong in mixing STL containers in, but some Qt concepts and parts of the API predates the STL's implementations, so they can be a pain to manage together, especially in threaded environments.

[aliks-os]

@kshegunov
Thank you, noted. As I see from various source code, nobody follow to some rule, and everyone writes it as he like.