[Development] unique_ptr and Qt, Take 2

Matthew Woehlke mwoehlke.floss at gmail.com
Mon Jun 17 17:36:37 CEST 2019

On 15/06/2019 14.24, Ville Voutilainen wrote:
> On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
>>>> 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.)
>>> That seems like a fairly minor problem. We either just pass the
>>> parent in, or make createChild do the child construction with the
>>> parent as an argument if that's valid, or fall back to reparenting if
>>> not.
>> I don't think createChild can/should assume that a QObject* ctor
>> parameter means "parent", i.e. it should *always* explicitly reparent.
> We should perhaps look at whether it could assume it. Or add overloads
> that do/don't.

Overloads could work.

I think assuming could be dangerous in the face of user types, but OTOH
maybe we should make it part of the API that if you have such types, you
are expected to provide a template specialization for your type that
Does The Right Thing.

The more I think about it, the more I suspect that's just the right
solution... make it work for Qt's own classes and user classes that
strictly follow "the rules", and just tell people to specialize it (or
just don't use it) otherwise, rather than trying to overengineer things.


More information about the Development mailing list