[Development] QProperty and library coding guide

Ville Voutilainen ville.voutilainen at gmail.com
Sun Jul 19 21:17:10 CEST 2020


On Sun, 19 Jul 2020 at 21:52, Thiago Macieira <thiago.macieira at 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?


More information about the Development mailing list