`QObject` is already pretty much a handle to the underlying data due to pimpl.
So that’s a good first step.
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`.
Q_OBJECT macro would have to define:
1. the Handle class,
2. Handle operator& that returns the handle instead of a pointer,
3. operator Handle()() to let an object reference be usable in the context of
an object handle.
Hopefully C++11 provides enough magic to allow deduction of the class’s type in
method definition without having to resort to Q_OBJECT(MyObject).
The event list and QPointer would use that handle instead of `QObject*`, of
course. qobject_cast would accept it too.
E.g. currently you may have
std::vector<MyObject*> objps; /* or */
std::vector<decltype(MyObject{}::parent())> objps;
std::list<MyObject> objs;
objs.emplace_back(…);
objps.push_back(&objs.back());
You would have:
std::vector<MyObject::Handle> objps; /* or */
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());
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.
I’m sure there’s plenty of stuff I’m missing. Please comment.
Cheers, Kuba
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
