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

[Koehne Kai]

> -----Original Message-----
> From: interest-bounces+kai.koehne=theqtcompany.com at qt-project.org
> [mailto:interest-bounces+kai.koehne=theqtcompany.com at qt-project.org]
> On Behalf Of Mikhail Matrosov
> Sent: Wednesday, October 15, 2014 11:57 PM
> To: interest at qt-project.org
> Subject: [Interest] Qt::MakePointer for creating QPointer as
> std::make_shared for creating std::shared_ptr
> 
> 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.

It's probably worth thinking about _why_ Stroustrup et al advocate not using 'naked' new/delete. The original proposal for unique_ptr lists a  couple of reasons (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3588.txt)

1. Consistency

'It will be possible to teach users "never say new/delete/new[]/delete[]" without disclaimers.' (and therefore advocate a style where the ownership model of a heap allocation is always explicit).

2. Less verbosity

  auto up = make_unique<LongTypeName>

 is just less noise than

  unique_ptr<LongTypeName> up(new LongTypeName(args))

3. Exception safety

More specifically, avoiding leaking if the constructor throws due to unspecified-evaluation-order in expressions like "foo(unique_ptr<X>(new X), unique_ptr<Y>(new Y))".


Let's see how these apply to your MakePointer:

1. Consistency

That's apparently your motivation. Anyhow, note that QPointer is - in contrast to std::unique_ptr, _not_ a free ride. It requires bookkeeping in t the target object, and also atomic operations on every access. So I'd strongly advocate you don't want to use QPointer for apps where performance matters.

(std::unique_ptr also isn't completely free btw either in debug builds, because it tends to generate lots of additional debug symbols. But that's another discussion ...)

Also, as Reinhardt Behm has pointed out, there are sometimes valid reasons to have a QObject pointer without a parent at construction time. So you might even not get away if removing 'naked' news completely.

2. Verbosity

That's only valid if you'd use a QPointer in the first place.

3. Exception safety

Whether exception safety is important to you, and you allow throwing of exceptions in any constructors, depends obviously on your code. Qt doesn't use exceptions itself though, and is also only exception safe to a limited degree ....

> 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 newoperations. 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?

Drawbacks are the additional price you pay for QPointer, see above. 

> 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.
> 
> 
> -----
> Best regards, Mikhail Matrosov