On Sun, 19 Jul 2020 at 21:52, Thiago Macieira <thiago.macie...@intel.com> wrote: > > On Sunday, 19 July 2020 08:20:01 PDT Thiago Macieira wrote: > > 1. Revert the feature. > > 2. Write papers to add necessary functionality to C++23, like reversing a > > pointer-to-member-object back to the containing object > > 3. Require C++23 in Qt 7.0 > > > > double Square::_qt_property_api_width::value() const > > { > > return retrieveContainer<&Square::width>(this)->d->width; > > } > > I've dug up my old idea of pointer-to-container. This can be implemented as a > standard library feature, without a core language change. > > Here's a test implementation modernised with C++17 NTTPs: > https://gcc.godbolt.org/z/GGGE1c > I *believe* it has no UB but does rely on implementation-defined behaviour of > a PMO. This IB works for QObject because we don't allow virtual inheritance > and also because by construction the type is only done on the class that > introduced the member. A generic solution of PMO reversal requires more work. > > In that sense, Peppe's suggestion of C++17 offsetof is better. > > The important detail is here: > static Klass *memberToContainer(Type pmo, ConstMemberType *member) > { > quintptr memberAddress = quintptr(member); > typename QIntegerForSizeof<Type>::Signed offset; > memcpy(&offset, &pmo, sizeof(offset)); > quintptr containerAddress = memberAddress - offset; > return reinterpret_cast<Klass *>(containerAddress); > } > > The memcpy is IB. The containerAddress calculation is the same as in the code > currently generated by moc, which I initially claimed to be UB, but now I'm > not sure.
Is there something in it that's UB besides what http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1839r2.pdf clarifies to become well-defined? _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development