[Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda

Daniel Teske Daniel.Teske at theqtcompany.com
Fri Feb 20 11:26:31 CET 2015

On Thursday 19 Feb 2015 15:41:42 Matthew Woehlke wrote:
> On 2015-02-19 15:21, Marc Mutz wrote:
> > On Thursday 19 February 2015 13:29:48 Daniel Teske wrote:
> >> more than 400 lambdas in Creator's source
> > 
> > Sounds like lambdas are overused (as any new language feature is overused
> > before it's fully understood by the resp. language community).
That is a useless contribution to this discussion.

> I'm not sure I've even *written* 400 lambdas yet :-), but I find myself
> using them most often in QObject::connect. Basically, a lambda saves
> writing a protected (or worse, *private*) slot by allowing the relevant
> code to be written inline. These are rarely more than a few lines long,
> and it's not unusual for them to be one-liners, e.g.:
>   connect(d->UI.scrollBar, &QAbstractSlider::valueChanged,
>           [d](int value){ d->scrollTo(value); });

That's one area. The others are too replace trivial interfaces with a low 
amount of virtual functions by a std::function properties. This can simplify 
code if e.g. the different implementations don't fit into a nice hierarchy.

Also lambdas make the standard algorithm useful. 
> The above is basically a private slot that's *actually private*. I've
> also had cases of needing to connect a signal to a slot where the slot
> needs to be called with additional (constant) arguments; these tend to
> look like the above also.
> Of course, the usual caveats of binding to a lambda apply, but in many
> cases those aren't issues (e.g. my MainWindow class is not going to
> disappear without taking its widgets with it, and said widgets aren't
> likely to be emitting signals from other threads).
> p.s. It would be cool if these restrictions could be relaxed by adding
> an overload that takes a QObject that "owns" the slot.
There is. 


More information about the Development mailing list