[Interest] Qt::MakePointer for creating QPointer as std::make_shared for creating std::shared_ptr

[Reinhardt Behm]

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.

I agree with you. Only because some people don't know how to do something 
correctly is no reason for doing it in a more complicated way than necessary. 
Educate the people and if after that they still don't know how to do it, don't 
let them do it.
In my area of avionics software, such unnecessary constructs would never pass 
certification.
-- 
Best Regards

Reinhardt Behm