Smart pointers in Qt
-
Hello,
I was reading about QSharedPointer in Qt. But I've not seen it much in use in source code of Examples and Demos. If we have smart pointers in Qt, why old C type pointers are preferred ?
-
"This is quite informative on the subject.":http://stackoverflow.com/questions/2454214/is-it-a-good-practice-to-always-use-smart-pointers
-
[quote author="situ117" date="1304279927"]
I was reading about QSharedPointer in Qt. But I've not seen it much in use in source code of Examples and Demos. [/quote]There are not so much Qt examples and demos with QSharedPointer because of the general concept for memory management in Qt using parent–child hierarchy of QObject.
A good article about available smart pointers in Qt and their purposes is: "Count with me: how many smart pointer classes does Qt have?":http://labs.qt.nokia.com/2009/08/25/count-with-me-how-many-smart-pointer-classes-does-qt-have/
Cheers,
Leon
-
Thanks for starting the topic. Especially the link presented by Leon is very informative.
Quite clear is the rationale of Qt for using their own smart pointers. There is no way to rely on external definitions as boost as long as these are not standard part of almost all compilers.
However, I am wondering, if there are strong arguments for switching to Qt's smart pointers when already using boost shared_ptr?
Any opinion of someone knowing the details of both implementations?
-
Both the QSharedPointer and the boost shared_ptr implement the same principle. There is no good reason to switch to one or the other unless you plan on ditching either of the libraries in the long run.
-
[quote author="koahnig" date="1304313628"]Thanks for starting the topic. Especially the link presented by Leon is very informative.[/quote]
I am glad that I was able to help :)
[quote author="Franzk" date="1304316838"]Both the QSharedPointer and the boost shared_ptr implement the same principle. There is no good reason to switch to one or the other unless you plan on ditching either of the libraries in the long run.[/quote]
I also share the opinion that sharing frameworks is not good idea. Qt is excellent framework (of course so is Boost) and Qt has all needed tools to create whatever you need.
Best regards,
Leon
-
-
The question is rather "why would you want to use smart pointers if plain pointers are completely sufficient". Smart pointers do not come for free, both time- and space-wise. Some operations are as quick/as small as for plain pointers, some are significantly more expensive. No need to pay that cost if there is no gain.
-
[quote author="Duck" date="1309378118"]The question is rather "why would you want to use smart pointers if plain pointers are completely sufficient". Smart pointers do not come for free, both time- and space-wise. Some operations are as quick/as small as for plain pointers, some are significantly more expensive. No need to pay that cost if there is no gain.
[/quote]It depends what you do if plain pointer are sufficient. YOu can surely always use plain pointers and do everything on your own, but why should you do that?
E.g. shared pointers: The objects are deleted, if the last shared pointer goes out of scope. If you do that with plain pointers, you have to implement ref counting etc. And there are many more types of shared pointers, e.g. QPOinter which goes to 0 if the object is destroyed from somewhere etc.
From my opinion, smart pointer are nearly always good to use!
-
Then again, C++ 0x allows compilers to generate garbage collection. If you have that, do you still need smart pointers for that?
Obviously, the problem is that it is optional: "implementation dependent". That means that a library like Qt can't rely on it.
Smart pointers are not always a good idea to use, but IMHO, they often are.
-
[quote author="Duck" date="1309378118"]The question is rather "why would you want to use smart pointers if plain pointers are completely sufficient". Smart pointers do not come for free, both time- and space-wise. Some operations are as quick/as small as for plain pointers, some are significantly more expensive. No need to pay that cost if there is no gain.
[/quote]The expence of smart pointers is certainly a reason to think twice.
[quote author="Andre" date="1309423297"]
Smart pointers are not always a good idea to use, but IMHO, they often are.[/quote]
Do you have an example?
Certainly it is not always the first choice to use pointers respectively smart pointers as already discussed above. I am wondering, if there are further situations where they are really not a good choise?
-
[quote author="koahnig" date="1309424953"]
[quote author="Andre" date="1309423297"]
Smart pointers are not always a good idea to use, but IMHO, they often are.[/quote]
Do you have an example?
Certainly it is not always the first choice to use pointers respectively smart pointers as already discussed above. I am wondering, if there are further situations where they are really not a good choise?
[/quote]One example may be the case where you store lots of pointers to objects in a container class. But, it all depends on your use case.
-
If you are in a time critical, real time issue, the indirection you get and perhaps the additional things to do, may hurt, as they cost time.
But in mobile and desktop apps, I think, it does not hurt.
-
[quote author="Andre" date="1309426243"]
One example may be the case where you store lots of pointers to objects in a container class. But, it all depends on your use case.
[/quote]That is a good example to be careful with smart pointers. If somehow the object/container survives so does the smart pointer and the allocated memory.
So a conclusion would be:
watch out for run-away containers ;-)[quote author="Gerolf" date="1309426319"]
But in mobile and desktop apps, I think, it does not hurt.[/quote]Well, if you are not careful enough, the run-away container may get you ultimately. Several GBs of memory are en vogue today, but ultimately you can drain any big pond (as long as you do not call it ocean) ;-)
-
[quote author="koahnig" date="1309429658"]
Well, if you are not careful enough, the run-away container may get you ultimately. Several GBs of memory are en vogue today, but ultimately you can drain any big pond (as long as you do not call it ocean) ;-)
[/quote]
Off topic:
See "here":http://www.google.nl/search?hl=nl&xhr=t&q=lake+aral&cp=0&nord=1&bav=on.2,or.r_gc.r_pw.&biw=1280&bih=963&ion=1&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi for how such a thing looks...
-
[quote author="koahnig" date="1309429658"]
[quote author="Gerolf" date="1309426319"]
But in mobile and desktop apps, I think, it does not hurt.[/quote]Well, if you are not careful enough, the run-away container may get you ultimately. Several GBs of memory are en vogue today, but ultimately you can drain any big pond (as long as you do not call it ocean) ;-)
[/quote]
But itÄs the same with pure pointers. You have to watch out to delete allocated memory. No chance to get around this problem, this or that way.
Where I love smart pointers is if you have some function that needs to allocate memory to read some values from Windows API where yxou have to pre allocate the memory. Just use some auto pointers and it will be destructed correctly when you leave the function, even in exception handling cases.
-
[quote author="Gerolf" date="1309430523"]
But itÄs the same with pure pointers. You have to watch out to delete allocated memory. No chance to get around this problem, this or that way.Where I love smart pointers is if you have some function that needs to allocate memory to read some values from Windows API where yxou have to pre allocate the memory. Just use some auto pointers and it will be destructed correctly when you leave the function, even in exception handling cases.[/quote]
Yes! However, one should be aware that auto_ptr does not mean automatically no problem at all.
I am certainly in favor of shared_ptr .[quote author="Andre" date="1309430218"]
Off topic:
See "here":http://www.google.nl/search?hl=nl&xhr=t&q=lake+aral&cp=0&nord=1&bav=on.2,or.r_gc.r_pw.&biw=1280&bih=963&ion=1&um=1&ie=UTF-8&tbm=isch&source=og&sa=N&tab=wi for how such a thing looks...
[/quote]:-D A good example !
-
[quote author="Gerolf" date="1309414170"]
It depends what you do if plain pointer are sufficient. YOu can surely always use plain pointers and do everything on your own, but why should you do that?
[/quote]Because they are cheap and fast.
[quote author="Gerolf" date="1309414170"]
E.g. shared pointers: The objects are deleted, if the last shared pointer goes out of scope. If you do that with plain pointers, you have to implement ref counting etc. And there are many more types of shared pointers, e.g. QPOinter which goes to 0 if the object is destroyed from somewhere etc.From my opinion, smart pointer are nearly always good to use![/quote]
From my point of view it's pretty much the opposite. Shared pointer impose overhead in lots of cases, so using them without justification violates the "don't pay if you don't need it" principle.
Often enough there appears to be a "need to use SharedPointers" to "fix" "issues" that arise typically from a design that does not have a clear concept of ownership.
Fortunately enough, in a QObject based world that's rather rare as most QObjects do have an owner. No need for any "manual" management here either.
Shared
-
Now that smart pointers are an integral part of C++ 2011, does that change any of the considerations here?
Specifically, does it render the Qt smart pointers obsolete?P.S. I just started C++ and Qt and I am very curious how to apply my freshly learnt C++ 2011 knowledge in combination with Qt.
My gut feeling says that C++ smart pointers will eventually override the QT and Boost smart pointers, so for new programs the C++ pointers might be best.
Anyone comments?
-
Now that smart pointers are an integral part of C++ 2011, does that change any of the considerations here?
Specifically, does it render the Qt smart pointers obsolete?P.S. I just started C++ and Qt and I am very curious how to apply my freshly learnt C++ 2011 knowledge in combination with Qt.
My gut feeling says that C++ smart pointers will eventually override the QT and Boost smart pointers, so for new programs the C++ pointers might be best.
Anyone comments?
-
Hi,
[quote author="gbonnema" date="1418984633"]Now that smart pointers are an integral part of C++ 2011, does that change any of the considerations here?
Specifically, does it render the Qt smart pointers obsolete?P.S. I just started C++ and Qt and I am very curious how to apply my freshly learnt C++ 2011 knowledge in combination with Qt.
My gut feeling says that C++ smart pointers will eventually override the QT and Boost smart pointers, so for new programs the C++ pointers might be best.
Anyone comments? [/quote]Qt smart pointers are not completely obsolete. Qt (and Boost) have more types of smart pointers than the C++11 standard. See the top answer at http://stackoverflow.com/questions/5026197/what-c-smart-pointer-implementations-are-available
Also note that QSharedPointer has the ability to perform "special casts":http://doc.qt.io/qt-5/qsharedpointer.html#objectCast on QObjects. std::shared_ptr doesn't have this ability.
Having said that, it is perfectly fine to use C++11 shared pointers in a Qt project.
-
Hi,
[quote author="gbonnema" date="1418984633"]Now that smart pointers are an integral part of C++ 2011, does that change any of the considerations here?
Specifically, does it render the Qt smart pointers obsolete?P.S. I just started C++ and Qt and I am very curious how to apply my freshly learnt C++ 2011 knowledge in combination with Qt.
My gut feeling says that C++ smart pointers will eventually override the QT and Boost smart pointers, so for new programs the C++ pointers might be best.
Anyone comments? [/quote]Qt smart pointers are not completely obsolete. Qt (and Boost) have more types of smart pointers than the C++11 standard. See the top answer at http://stackoverflow.com/questions/5026197/what-c-smart-pointer-implementations-are-available
Also note that QSharedPointer has the ability to perform "special casts":http://doc.qt.io/qt-5/qsharedpointer.html#objectCast on QObjects. std::shared_ptr doesn't have this ability.
Having said that, it is perfectly fine to use C++11 shared pointers in a Qt project.
-
bq. std::shared_ptr doesn’t have this ability.
yes it does, see std::dynamic_pointer_cast<>().
-
bq. std::shared_ptr doesn’t have this ability.
yes it does, see std::dynamic_pointer_cast<>().
-
[quote author="sandy.martel" date="1420514147"]bq. std::shared_ptr doesn’t have this ability.
yes it does, see std::dynamic_pointer_cast<>().
[/quote]std::dynamic_pointer_cast() is analogous to QSharedPointer::dynamicCast(),. It relies on RTTI.I was referring to QSharedPointer::objectCast(), which has no analogue in standard C++. It relies on Qt's "meta-object system":http://doc.qt.io/qt-5/metaobjects.html (no RTTI support required).
QSharedPointer::objectCast() works reliably across DLL boundaries, but QSharedPointer::dynamicCast() and std::dynamic_pointer_cast() don't.
-
[quote author="sandy.martel" date="1420514147"]bq. std::shared_ptr doesn’t have this ability.
yes it does, see std::dynamic_pointer_cast<>().
[/quote]std::dynamic_pointer_cast() is analogous to QSharedPointer::dynamicCast(),. It relies on RTTI.I was referring to QSharedPointer::objectCast(), which has no analogue in standard C++. It relies on Qt's "meta-object system":http://doc.qt.io/qt-5/metaobjects.html (no RTTI support required).
QSharedPointer::objectCast() works reliably across DLL boundaries, but QSharedPointer::dynamicCast() and std::dynamic_pointer_cast() don't.
-
bq. I was referring to QSharedPointer::objectCast(), which has no analogue in standard C++. It relies on Qt’s meta-object system [doc.qt.io] (no RTTI support required).
dynamic_cast is the analogue to qobject_cast, and RunTime Type Information is the (lot less feature rich) analogue to the meta-object system. Well, it's the other way around actually.
bq. QSharedPointer::objectCast() works reliably across DLL boundaries, but QSharedPointer::dynamicCast() and std::dynamic_pointer_cast() don’t.
I remember having problem with this, but that was 15 years ago, I think it's mostly resolved now. On the other hand, it's pretty easy for a naive user to get qobject_cast to fail across dll boundaries. Just add the HEADERS of your shared class to both projects, the dll and the main. It's just a header shouldn't cause any harm? MOC will run twice, you'll end up with duplicate meta objects and qobject_cast will silently failed. The dynamic_cast problem was the same in earlier gcc, duplicate typeinfo data for the same class, but it seems to work reliably now.
-
bq. I was referring to QSharedPointer::objectCast(), which has no analogue in standard C++. It relies on Qt’s meta-object system [doc.qt.io] (no RTTI support required).
dynamic_cast is the analogue to qobject_cast, and RunTime Type Information is the (lot less feature rich) analogue to the meta-object system. Well, it's the other way around actually.
bq. QSharedPointer::objectCast() works reliably across DLL boundaries, but QSharedPointer::dynamicCast() and std::dynamic_pointer_cast() don’t.
I remember having problem with this, but that was 15 years ago, I think it's mostly resolved now. On the other hand, it's pretty easy for a naive user to get qobject_cast to fail across dll boundaries. Just add the HEADERS of your shared class to both projects, the dll and the main. It's just a header shouldn't cause any harm? MOC will run twice, you'll end up with duplicate meta objects and qobject_cast will silently failed. The dynamic_cast problem was the same in earlier gcc, duplicate typeinfo data for the same class, but it seems to work reliably now.
-
[quote author="sandy.martel" date="1420588259"]it's pretty easy for a naive user to get qobject_cast to fail across dll boundaries. Just add the HEADERS of your shared class to both projects, the dll and the main. It's just a header shouldn't cause any harm? MOC will run twice, you'll end up with duplicate meta objects and qobject_cast will silently failed.[/quote]Ah, I hadn't seen this before. Thanks for enlightening me.
-
[quote author="sandy.martel" date="1420588259"]it's pretty easy for a naive user to get qobject_cast to fail across dll boundaries. Just add the HEADERS of your shared class to both projects, the dll and the main. It's just a header shouldn't cause any harm? MOC will run twice, you'll end up with duplicate meta objects and qobject_cast will silently failed.[/quote]Ah, I hadn't seen this before. Thanks for enlightening me.
-
@sandy.martel : Aren't you describing a wrong usage of HEADERS ? INCLUDEPATH should be used to use a header from a library project and not HEADERS
-
@sandy.martel : Aren't you describing a wrong usage of HEADERS ? INCLUDEPATH should be used to use a header from a library project and not HEADERS
-
Well, obviously this wrong, since it doesn't work correctly.
-
Well, obviously this wrong, since it doesn't work correctly.
