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

[Bo Thorsen]

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.


-- 
Viking Software
Qt and C++ developers for hire
http://www.vikingsoft.eu