[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