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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development