[Development] Would it make sense to make QObject moveable in Qt 6?

[Kuba Ober]

> On Aug 25, 2016, at 5:48 AM, Marc Mutz <marc.mutz at kdab.com> wrote:
> 
> On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote:
>> `QObject` is already pretty much a handle to the underlying data due to
>> pimpl. So that’s a good first step.
> 
> I challenge the notion that QObject is a handle to date.
> 
> QObject is first and foremost the base class of a polymorphic class hierarchy.
> 
> If you wrap that in a parallel value-like-but-not-quite class hierarchy, you 
> end up with QDomNode. I don't like QDomNode. Do you like QDomNode?
> 
> That said, the Copperspice guys argue that the implicit memory management of 
> QObject parent-child relationships is becoming alien for C++ developers. The 
> Qt community can of course deny every claim that comes from that direction, 
> but sometimes the look of an outsider is valuable, too. After all, the API 
> quality matters most for newbies, not decade-long Qt users.
> 
> So IMO, it's certainly worth asking the question whether we should change 
> something there, e.g. by using shared_ptr/weak_ptr to manage lifetimes.
> 
> That would cover your use-case:
> 
>   std::vector<std::shared_ptr<QObject>>
> 
> is all you were asking for.

This is fine and dandy except we’re holding shared pointers to pointers to data. That seems a bit wasteful when we know that internally it’s just Qt’s unique_ptr (QScopedPointer).

I think that people would understand the fallout from QObject being movable if it was clearly documented, e.g. that if you hold any pointers to it, and then move it, the pointers aren’t valid. A QPointer that tracks the moves in principle is what anyone could use to track an object that has been moved, but it’d break its api a bit: after every move, the QPointer would return a different address. A QObject::Handle would be a cheaper version of a QPointer: it wouldn’t track destruction, but otherwise would work the same. Perhaps we could name it better?

A movable QObject could be at the beginning just an implementation detail, and perhaps Qt shouldn't be moving any objects that are visible to the user. But internally it would track the moves all across the hierarchy. I’d need to see what the fallout of that would be, otherwise this will all be idle talk. I’ll see what an implementation would look like.

Kuba