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

Reinhardt Behm rbehm at hushmail.com
Fri Oct 17 08:42:26 CEST 2014


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.

-- 
Best Regards

Reinhardt Behm





More information about the Interest mailing list