[Development] unique_ptr and Qt, Take 2
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
> 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.
> Me: <unsubstantiated conjecture, with suggestion that facts could change
> 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