QObject and std::unique_ptr do the same thing

[zander]

I noticed in your code that you created a private member that is a unique pointer which holds a QObject inherting object. In the following case a QThreadPool.

https://github.com/cculianu/Fulcrum/blob/65bc0fe4fb57e27c4c55554350317cef304c4c17/src/ThreadPool.h#L121

When a QObject is deleted all the children of it are also deleted. So you don't need the unique_ptr, all you need to do is pass in 'this' to the constructor of the QThreadPool. Then when your class is deleted it will delete the pool member anyway.

[cculianu]

Yes, I am aware of this. They are not identical though.

I used std::unique_ptr there to control when the obejct is deleted. Sometimes you want an object deleted before the destructor finishes destructing the object in the most derived class. If you rely on QObject parent/child destruction, it will be killed in the QObject base destructor, when the object loses its type for the derived class. So using std::unqiue_ptr there guarantees it will be deleted early.

[cculianu]

Consider that the object was created when App existed as an App, and it relies on App being App during its lifetime.. It is asymmetrical to create it within App and then to kill it after App is no longer App.

What's more -- the destructor of ThreadPool relies on App being alive during its entire lifetime (App contains the logger it uses to log messages).

So no, they are not at all identical.

(Similar? Yes, for some usages. Identical? No.)

[zander]

Apologies, I assumed you were unaware of the Qt feature. Seems your usecase is much more complex than my quick read made me think.