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