[Interest] Requesting QObject::bind() method

Thiago Macieira thiago.macieira at intel.com
Fri Mar 24 00:50:33 CET 2017


On quarta-feira, 22 de março de 2017 05:50:47 PDT Jean-Michaël Celerier wrote:
> >  QObject::bind(sender, &Sender::signalName, receiver, &Receiver::setter);
> > 
> > This is exactly connect() we already have.
> 
> I think that bind adds one more step : it does the set. ie. bind would be :
> 
>      QObject::bind(sender, &Sender::signalName, &Sender::getter, receiver,
> &Receiver::setter);
>
> and would be equivalent to :
> 
>     QObject::connect(sender, &Sender::signalName, receiver,
> &Receiver::setter);
>     receiver->setter(sender->getter());

The new value is already carried by the signal. We don't need the getter: my 
code examples already compile.

> Now, about the overall string problem, I think that most people would
> rather do :
> 
>      QObject::bind(sender, "source", receiver, "target");
> 
> And actually, with modern C++, this can be made typesafe : for instance the
> boost.metaparse guys are
> able to convert (constexpr) strings to types :
> http://www.boost.org/doc/libs/1_63_0/doc/html/metaparse.html
> at compile time. So it would not be unthinkable to have moc generate the
> appropriate parser and "compile-time property" class

As long as the property name is in a string, forget it. We need an actual C++ 
identifier with the property's type somewhere. As I said, that's either the 
getter or the signal. And since you can use the signal in connect()...

> At the end of this mail there is an example implementation (that uses a
> string literal from boost.hana) and allows to do the following at
> compile-time:  (requires c++17; I tested with clang 4 and I believe gcc 7
> would work)

I'll just stop reading here. If it requires Clang 4 and GCC 7 and probably 
doesn't with with MSVC 2017, we can discuss this in 2023.

>     bind(sender, "source"_s, receiver, "compatibleTarget"_s);
> 
> While this won't compile
> 
>     bind(sender, "source"_s, receiver, "incompatibleTarget"_s);
> 
> So the SIGNAL() and SLOT() macros could maybe be modified this way (Qt6
> anyone ? ;p) to have compile-checked versions (SSIGNAL() / SSLOT()).

Why? We have a perfectly working method that uses PMFs and delivers to 
callables, without additional magic.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center




More information about the Interest mailing list