[Development] [RFC] What to do about overloaded signals/slots?

Olivier Goffart olivier at woboq.com
Fri Oct 18 10:33:08 CEST 2013


On Monday 07 October 2013 16:49:18 Grégoire Barbier wrote:
> I agree that getting rid of runtime warning and being warned at compile
> time is better. Such as when calling an inexistant slot or a slot which
> has changed its signature.
> 
> However in the refactor case I think there are cases (I though moving a
> slot to a base class but you say I'm wrong) where there were no runtime
> warning but a still working connection after the refactoring.

>[...]  maybe the contrary: moving a slot to child class.

It was moving a slot from a base to a derived class.  and if you wrote 
&Base::slot you have to change to &Derived::slot.

I don't think it is a big deal.  What do you do more often?  Move a slot from 
a base to a derived,  or add an argument to a signal? (the latter used to 
break and is now still working)

> > Using some c++11, I was able to make a macro that might make the syntax
> > easier:
> > 
> > template <typename Type, typename T> struct Helper;
> > template <typename Type, typename... Args> struct Helper<Type,
> > void(Args...)> {
> > 
> >      template <typename Ret> static auto help(Ret (Type::*func)(Args...))
> >      
> >                    -> decltype(func) { return func; }
> >      
> >      template <typename Ret> static auto help(Ret (Type::*func)(Args...)
> >      const)
> >      
> >                    -> decltype(func) { return func; }
> > 
> > };
> > 
> > 
> > #define GET_METHOD(OBJ, FUNC, ARGS) (OBJ),  [&](){ \
> > 
> >    typedef std::remove_reference<decltype(*(OBJ))>::type Type; \
> >    return Helper<Type, void ARGS>::help(&Type::FUNC); }() \
> > 
> > To be used like this:
> >   connect( GET_METHOD(process, error, (QProcess::ProcessError)) ,
> >   
> > 		GET_METHOD(receiver, mySlot, ());
> > 
> > It is quite similar to the old syntax but benefits from the adventage on
> > the new one.  But it needs lambda and decltype,   and one yould need to
> > reimplement it for each argument types
> 
> This sounds great :-)
> Something like the best of both pre-Qt5 macros and Qt5 compile-time type
> checking, if I understand well the code.
> So, I'm impatient to get rid of my not-c++11-ready target platforms.

(question: which not-c++11-ready target platform do you still target?  (OSX 
10.6's gcc 4.2 perhaps?)  )

> Moreover am I wrong or is this fully source-compatible with the
> refactoring we talked about (moving a slot across parents and children
> classes) and with overloading slots ?

Yes, fully source compatible.

> But probably not binary-compatible.

The refactoring itself is not binary compatible. (as you could also have 
called the slot directly)

-- 
Olivier

Woboq - Qt services and support - http://woboq.com - http://code.woboq.org




More information about the Development mailing list