[Development] unique_ptr and Qt, Take 2
qt at squorn.de
Fri Jun 21 15:16:49 CEST 2019
>> The minor problem being that to not so small audiences,
>> new Whoosh(something);
>> just looks like a bug, and then you need to look three times to
>> realize that something is a parent.
> Sure... but `something.createChild<Whoosh>()` can help with that.
> OTOH, I just realized a problem with that... when the new child needs to
> take its parent in the ctor for other reasons. I don't know if there is
> an easy solution to that. (Of course, you can still pass the parent with
> createChild, but then you've violated DRY.)
There are multiple different implementations of createChild.
The one I did choose requires the class to have a tagged ctor, meaning a
ctor whose first parameter is QParentPtr<QWidget *> parent, so the ctor
still has access to the actual parent ptr, and createChild simply passes
the this pointer as the first parameter.
The drawback is obviously that requires new ctors, but there are several
* It is easier to do than having a later reparenting. Writing the new
ctors is trivial.
* It allows for designing classes that can only created with a parent
* The cost of creating new ctors is only for those that want to make use
* The new ctors have clear ownership semantics
In that patch, I've also added new ctors that take no parent ptr, to be
used with make_unique or for stack-allocation.
And the last puzzle piece is that the qt users can choose to deprecate
the old existing ctors, thus users can choose between:
* Keep just using Qt as is
* Make use of createChild by providing new ctors
* Ensure that each memory allocation is either parented or held in a
unique_ptr, by opting into the deprecation + using some kind of code
analysis preventing usage of raw news.
And obviously that's also the way, a existing code base could be
The actual implementation of that mechanism is in:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development