[Development] QProperty and library coding guide

[Volker Hilsheimer]

> On 17 Jul 2020, at 14:28, Giuseppe D'Angelo via Development <development at qt-project.org> wrote:
> 
> Il 17/07/20 14:09, Ulf Hermann ha scritto:
>>>> QAction *action = ~~~;
>>>> auto prop = action->text;
>> This already gives you the string. You cannot retrieve the property
>> itself. You can alternatively do action->text() or action->text.value().
>> They all do the same thing.
> 
> Uhm... sorry, no, this doesn't really compute for me. Ignore the copy semantics for a second (use const auto &, if necessary), what's decltype(prop)? If it's QString, then you can't write .value() after it.
> 
> 
>> The member to access in the private object is hardcoded in the generated
>> implementation of value(). The public object to pick the private object
>> from is retrieved by offset from the address of the property. moc
>> generates code like this:
>> qreal QQmlComponent::_qt_property_api_progress::value() const
>> {
>>      const size_t propertyMemberOffset =
>> reinterpret_cast<size_t>(&(static_cast<QQmlComponent
>> *>(nullptr)->progress));
>>      const auto *thisPtr = reinterpret_cast<const QQmlComponent
>> *>(reinterpret_cast<const char *>(this) - propertyMemberOffset);
>>      return thisPtr->QQmlComponent::d_func()->progress.value();
>> }
>> I see where you're coming from. If the address doesn't exist, this
>> shouldn't be possible. However, no_unique_address does not mean that the
>> object has no address. It just means that it can share the same address
>> with other objects.
> 
> No, actually this makes perfect sense, but was contradicted before:
> 
>> We are not casting these structs to or from anything though, do we?
> 
> So yes, you're casting them to perform pointer arithmetic and figure out the address of the object to get the property from.


Indeed. My mistake, thanks for correcting me. When I formulated my assumption as a question, it was indeed meant that way :)

Cheers,
Volker