[Development] unique_ptr and Qt, Take 2

[Matthew Woehlke]

On 14/06/2019 17.05, Ville Voutilainen wrote:
> On Fri, 14 Jun 2019 at 00:36, Matthew Woehlke 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.

I don't think createChild can/should assume that a QObject* ctor
parameter means "parent", i.e. it should *always* explicitly reparent.

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);

OTOH I don't think such classes are common. (I know my own code contains
a few, but I'm not sure there are any in Qt itself.)

>>> [...] 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.

> nor do I know what "properly owned" signal/slot connections are.

Connections which have both a sender and receiver owner, such that they
disappear when *either* is destroyed... and in particular, when the
receiver is the owner of any resources used in the slot. (Although, this
really only became relevant with Qt5 when you could use lambdas as slots.)

>>> 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.
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.

-- 
Matthew