> Since in modern Qt you connect signals to functions/lambdas, is there a reason to declare slots anymore?
Interesting question, I've thought about this also. IMHO, deep consideration is important: "slot": A "slot" is a non-coupling thread-safe execution bridge. It's already been mentioned in this thread: Current Qt slots provide (beyond lambdas): (1) Queued connections (2) Runtime-reflected connections (3) Uncoupled connections Current slot implementation bridges runtime-reflection capabilities (provided by QMetaObject), and provides the thread-safe event queue that bridges "slot-execution" to occur on the "target-thread" for which the "target-QObject" has "affinity". Lambdas alone cannot do this -- some kid of "event-queue" would be required that is "thread-aware" (yes, could be provided through a library of some kind, that happens to be what Qt is doing). Because Qt slots can rely upon runtime type-reflection (provided by QMetaObject), we can also couple signal/slot across two objects where the code does not include both headers. This is sometimes important to enable designs for an "uncoupled-bridge" across components that cannot be coupled. However, I agree that for the "common-case" (perhaps 80% of the time for "typical" designs?) that lambdas are just-plain-awesome. --charley
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest