[Development] QProperty and library coding guide

Volker Hilsheimer volker.hilsheimer at qt.io
Tue Jul 21 23:18:15 CEST 2020

> On 21 Jul 2020, at 22:51, Ville Voutilainen <ville.voutilainen at gmail.com> wrote:
> On Tue, 21 Jul 2020 at 23:48, Ville Voutilainen
> <ville.voutilainen at gmail.com> wrote:
>> On Tue, 21 Jul 2020 at 22:12, Thiago Macieira <thiago.macieira at intel.com> wrote:
>>> On Tuesday, 21 July 2020 10:40:27 PDT Ville Voutilainen wrote:
>>>> A very significant goal of this exercise is achieving notational
>>>> convenience. Theoretical concerns about UB
>>>> in the presence of papers that apparently excise that UB shouldn't
>>>> stand in the way of that goal.
>>> Sorry, I don't agree. We can't use something that is unimplementable.
>> Oh, when did that change? Was qobject_cast changed not to be UB?
> See also all the memcpys that are done with types that are
> polymorphic, and the ones
> where we memcpy types that have user-provided copy operations. qtbase
> is UB left right
> and center, but it's certainly interesting that when a new thing in it
> might be clarified
> not to be UB after all, we perform all kinds of somersaults to avoid
> such dark corners.

With the current design, notational convenience doesn’t work either:

auto text = qAction->text;
text.left(10); // booh

‘text’ is not a QString, but a QAction::_qt_property_api_text object, with broken... everythings.

And if people can’t use auto, then you can’t use standard ranged-for to iterate over container type properties without spelling everyhing out. That’s ... not convenient, I suppose. And that problem persists, even if we expose a e.g QProperty<QStringList> reference through a public property member.

The current implementation also adds, in case of us not being able to use no_unique_address,  a byte or even a pointer to each class in a class hierarchy, bloating classes down in the inheritance tree. Plus the BC challenge that might come with in the long run.

So, this is not only a problem of UB. There is well defined behavior that seems to get in the way.


More information about the Development mailing list