[Development] Property bindings in Qt 6

Matthew Woehlke mwoehlke.floss at gmail.com
Mon Sep 30 20:06:18 CEST 2019


On 30/09/2019 12.38, Ville Voutilainen wrote:
> On Mon, 30 Sep 2019 at 19:12, Matthew Woehlke wrote:
>>>     QProperty<QString> fullname;
>>>     fullname.setBinding([&]() { return surname() + " " + lastname(); });
>>
>> I suppose this is convenient, but it also means creating a new function
>> object for *every instance of the type*. A more "traditional" approach
>> would only have *one* member function (that is called with the implicit
>> 'this' parameter).
>>
>> Have you at least considered doing something similar here, i.e. instead
>> of using a capturing lambda, instead use a stateless function that takes
>> the owning class as a parameter?
> 
> Which owning class?

The class which has a property (QProperty).

> How does that avoid making it a template anyway?

I don't understand how that relates?

With the code like the above, I am creating a new lambda for every
instance of the owning class, due to that lambda necessarily containing
state (namely, the reference-captured `this`).

It seems to me I could refactor this to take a `T (*)(Owner*)`, or at
least the std::function equivalent, which would allow at least the above
example (and, I would expect, most uses) to use a stateless function. As
illustrated by Simon, *all* uses *must* use a state-containing functor.

(Note: I did not check if the "real" implementation actually does this
already and the illustration in the OP was just for brevity.)

IOW, the example would look like:


  fullname.setBinding(
    [](Foo const* self){
      return self->surname() + " " + self->lastname();
    });

This *might* be able to not only story just a function pointer, but
store it statically for all instances of the specific property, which is
much closer to the storage requirements for a "traditional" getter. As
illustrated, the design must store a lambda with state for every
*instance* of the property.

Convenience is nice, but as presented, it seems to come at a non-trivial
storage cost.

-- 
Matthew


More information about the Development mailing list