Smart pointers in Qt
-
[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.
-
[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.
