Den 17-10-2014 10:32, Mikhail Matrosov skrev: > On Friday 17 October 2014 09:00:08 Bo Thorsen wrote: > >/ Den 17-10-2014 08:42, Reinhardt Behm skrev: > />/ > On Thursday 16 October 2014 01:56:46 Mikhail Matrosov wrote: > />/ >> Hello! > />/ >> > />/ >> In modern C++ there is almost no need to use raw *new* and *delete*. > As > />/ >> Bjarne Stroustrup is saying in his “A Tour of C++”: “Avoid ‘‘naked’’ > new > />/ >> and delete operations; §4.2.2.”. We use standard containers and smart > />/ >> pointers for that, with std::make_shared and std::make_unique > functions > />/ >> for > />/ >> smart pointers creation. > />/ >> > />/ >> In Qt we also have QSharedPointer and QSharedPointer<T>::create(…) > />/ >> method. > />/ >> But we don’t use smart pointers in Qt much, due to parent-driven > memory > />/ >> model. And most of QObjects are created with raw *new* operations. > Maybe > />/ >> it > />/ >> is a proper thing to add some C++14-style wrapper for creating > QObjects > />/ >> > />/ >> like this: > />/ >> 1. namespace Qt <http://qt-project.org/doc/Qt.html> > />/ >> 2. { > />/ >> 3. template<class T, class... Args> > />/ >> 4. QPointer <http://qt-project.org/doc/QPointer.html><T> > />/ >> MakePointer( > />/ >> Args&&... args) > />/ >> 5. { > />/ >> 6. T* pObject = new T(std::forward<Args>(args)...); > />/ >> 7. Q_ASSERT(pObject->parent() != nullptr); > />/ >> 8. return pObject; > />/ >> 9. } > />/ >> 10. } > />/ >> > />/ >> Now, one can safely call Qt::MakePointer to create a QObject and be > sure > />/ >> it > />/ >> will not leak due to an assertion for an existing parent. And it will > />/ >> free > />/ >> all the calling code from raw *new*operations. One can always use raw > />/ >> *delete* to destroy the object, but he does not have to. And even if > he > />/ >> will, it will not lead to dangling pointers problem since QPointer is > />/ >> automatically set to null in this case. > />/ >> > />/ >> I’m planning to use this approach in my code. Do you think it is > />/ >> relevant? > />/ >> Are there any drawbacks? > />/ >> > />/ >> PS This is a cross-post of my question from Qt forums: > />/ >>http://qt-project.org/forums/viewthread/48541, where SGaist > />/ >> <http://qt-project.org/mebmer/39728> suggested me to post here. > />/ > > />/ > This looks to me like a complicated solution to a non existing problem. > />/ > > />/ > Your method will fail for objects that should not have a parent, e.g > top > />/ > level windows or objects that are created to be moved to anther thread > to > />/ > name just a few. > />/ > In all other cases where you do not want an object to be an orphan (no > />/ > parent) just don't give a default for the usual parent parameter in the > />/ > constructor and check it inside the constructor for parent being > />/ > non-null. This way an ASSERT will give a meaningful message. > />/ > > />/ > In most cases when I need an QObject without parent I create it on the > />/ > stack (no explicit new/delete) because it is just a local variable and > />/ > the compiler take care of creation and destruction. > />/ > Others are created with new and directly have a parent or widgets are > />/ > placed into layouts and get a parent this way. > />/ > > />/ > Just because Bjarne Stroustrup has said it, does not mean it make > sense in > />/ > this context and has to be blindly followed even if it make code more > />/ > complex. He also said to write _clear_code_. And this takes precedence, > />/ > at least for me. > />/ > />/ I have had this discussion with countless customers. I almost never use > />/ smart pointers, except to do exception safety. And that's only with a > />/ QScopedPointer. > />/ > />/ Using a shared pointer is to me a violation of a couple of my most > />/ fundamental coding rules: Ownership and responsibility. I usually know > />/ exactly what object owns and controls other objects. So when the owner > />/ think it's time to delete the object, the object will be deleted. Using > />/ a shared pointer would mean the object lives on to some unknown time. > />/ > />/ QPointer is essentially a weak pointer, but one that doesn't rely on a > />/ shared pointer. I use that a lot. > />/ > />/ There are cases where an object has it's own life and in those cases it > />/ is a possibility that shared pointers are valid. Network code in boosts > />/ ASIO (which is IMHO completely overengineered, so this might be a bad > />/ example) is one case. > />/ > />/ The *only* argument I have ever heard for shared pointers that have some > />/ validity is that companies do not have senior C++ experts only. In the > />/ real world, they employ junior people or people coming from Java or C#. > />/ Giving them shared_pointers is a way to take away a lot of the cases > />/ where you shoot yourself in the foot. > />/ > />/ The counter argument is that they never learn The Right Way if you don't > />/ just throw them in and see if they swim. Then they can return to Java :D > />/ > />/ I disagree with Reinhardt that it's a non-existing problem. But I also > />/ disagree with Stroustrup that shared pointers are the solution to it. > />/ Education in OO and C++ is IMHO the proper solution. > />/ > />/ Bo./ > > Bo, you've said a lot about smart pointers, but I didn't get your > thought on the proposed solution. Except you are using QPointer a lot > (I suggest you are not calling it smart pointer, right?). > > What do you think of the Qt::MakePointer function, or maybe you have > any ideas on how it should look or maybe on some different but related > approach? Since you agree that problem exists.
I just use new and delete, and I won't change that. If others want to add syntactic sugar, I don't care about it. As long as it's not in my code :) Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest