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

Thiago Macieira thiago.macieira at intel.com
Wed Aug 24 21:42:29 CEST 2016


On quarta-feira, 24 de agosto de 2016 14:05:56 PDT Kuba Ober wrote:
> `QObject` is already pretty much a handle to the underlying data due to
> pimpl. So that’s a good first step.

Except that everything refers to QObjects by pointer. QObject is not a holder 
to the private data, its address *is* the data.

And its address is copyable, so if we replaced the pointer with something, 
we'd have to use something copyable and non-owning.

> To support this, the `QObject*` (and derived types) would be replaced with
> `QObject::Handle` that keeps a pimpl C pointer. E.g. we’d have
> `QObject::Handle * QObjectData::parent, QList<QObject::Handle>
> QObjectData::children`.

Major API break. I doubt we can accept that.

> std::vector<decltype(MyObject{}::parent())> objps; std::vector<MyObject>
> objs;
> objs.emplace_back(…); /* or */ objs.push_back(std::move(some_instance));
> // alternative 1 - an object is convertible to a handle
> objps.push_back(objs.back());
> // alternative 2 - an address of an object is a handle
> objps.push_back(&objs.back());

As I said, the solution would need to be copyable, not just movable. So I 
think it throws everything you suggested into question. I've ignored the rest 
of your email that assumes that a movable solution is possible.

> I’d have to test it on some large code bases to see how much work it’d imply
> in terms of source-code incompatibility. To aid in porting,
> QT_LEGACY_OBJ_HANDLE would make all `AnyObjectClass::Handle` convertible to
> `AnyObjectClass*` to make this aspect source-compatible with Qt 5.

That's everything that exists today.

> I’m sure there’s plenty of stuff I’m missing. Please comment.


-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Development mailing list