[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