On Sat, 15 Jun 2019 at 02:30, Matthew Woehlke <mwoehlke.fl...@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. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
