[Development] unique_ptr and Qt, Take 2

[Ville Voutilainen]

On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke <mwoehlke.floss at gmail.com> wrote:
>
> On 13/06/2019 16.09, Ville Voutilainen wrote:
> > 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.)

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.

> >> That's one of the things I love about Qt; object hierarchies give me
> >> working dynamic memory management without needing even smart pointers.
> >
> > That's the one thing that makes me queasy about using Qt in large
> > applications; I always need to worry about ownership relationships,
> > because I can't program with smart pointers.
> I guess your mileage varies. My experience has been the opposite.
>
> To be fair, I expect a lot of that is "instinctive"... that is, when you
> come from a background where not using smart pointers is scary, the Qt
> way is probably going to rub you the wrong way, even though it's nowhere
> near as dangerous as your experience causes you to believe. Conversely,

My experience with Qt matches my previous experience. Memory leaks are
easy to introduce, and avoiding them is not trivial.

> being comfortable with Qt and its minimal need for smart pointers likely
> produces an aversion to sprinkling them everywhere "because it's safer".

Interesting conjecture; there's no quotation marks in the actual
rationale for programming
with smart pointers without using raw pointers across a codebase, and
that reason is
that it's proven to work.

> > [...] 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, nor do I know what
"properly owned" signal/slot connections
are.

> > On Thu, 13 Jun 2019 at 22:54, Matthew Woehlke wrote:
> >> My "concern", and possibly why everyone fixated on the unique_ptr stuff,
> >> is how wide-sweeping the necessary API changes will be. Modifying every
> >> method, everywhere, that reparents a QObject is a little intimidating.
> >> (Maybe you have some WIP that can put this into perspective?)
> >
> > Like https://codereview.qt-project.org/c/qt/qtbase/+/260618 ?
>
> Uh... yeah, I suppose. And... yeah. Yike. That's a scary (or at least
> intimidating) amount of API churn. In particular, there are enough files
> being touched to strongly discourage me even looking at the diffs...

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. It shouldn't
come as a surprise to anyone that
adding smart pointer support to APIs that didn't have it before
requires churn, because smart pointers
don't just drop into raw pointer APIs - by design.