[Development] unique_ptr and Qt, Take 2

Ville Voutilainen ville.voutilainen at gmail.com
Sat Jun 15 20:24:00 CEST 2019

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.

> So I don't see a way that such classes can avoid writing:
>   parent.createChild<Whoosh>(parent, ...);
> ...which means we wrote 'parent' twice, vs.:
>   new Whoosh(parent);

Yeah, and that seems like a very minor problem to me.

> >>> [...] the largeish application was leaking like a sieve and doing
> >>> use-after-free in all too many places.
> >>
> >> QPointer is great for avoiding this :-). (Also, properly "owned"
> >> signal/slot connections.)
> >
> > I fail to see how QPointer helps with that,
> Proper use of QPointer can certainly help with use-after-free.

Right, but not with automatic cleanup.

> > I don't know what to do with that. You asked whether there's a WIP,
> > and after being pointed to such a WIP, you are applying a yardstick
> > to it and then saying that you're discouraged from even looking at
> > it, because it violates your arbitrary yardstick requirement.
> I suggested that perhaps folks were intimidated by Daniel's proposal
> because "modifying every method, everywhere, that reparents a QObject is
> a little intimidating." As I'd overlooked the patch, I was just guessing
> at how much churn there would be. Subsequently looking at the patch
> confirmed my suspicion.
> IOW:
> Me: <unsubstantiated conjecture, with suggestion that facts could change
> opinion>
> You: <relevant facts>
> Me: Okay, sticking with my original conjecture.
> I don't know what to do with your "arbitrary yardstick" comment. Large
> code changes tend to be intimidating, and (in many cases) rightly so.

To each their own. Large and complicated changes being intimidating I
can have sympathy
for, large and simple changes not so much.

More information about the Development mailing list