1

Topic: Lambda [and] and [=]

Greetings to all. I can not answer for myself on  a question: In what cases it is useful to use [and] and [=] instead of explicit  a dial-up of parameters? From pluses I have only one argument - very much laziness to register arguments, but it is an argument so-so since if the lambda uses   variables, it already any not the correct lambda, and if their only 1... 4 and to enumerate not a problem. Besides, we completely supervise that happens inside. From  [&=] - it is more difficult to trace area of usage of a variable. In a case with and we can casually spoil something on a stack, for example, instead of constant function, can be caused , thus after lambda end is ready  predict that has been changed. In a case [=] someone above on a stack creates heavy object for copying and the lambda copies it, too it is bad... And so, who can result arguments for [&=]?

2

Re: Lambda [and] and [=]

ffk: ffk> I can not answer for myself on  a question: In what cases it is useful to use [and] and [=] instead of explicit  a dial-up of parameters? Me personally [and] in overwhelming majority of cases quite suffices. Explicitly to specify captured variables I see sense only in two rarely meeting cases: 1) when for different variables it is favourable to use different methods of capture (under the link and on value), 2) when the lambda is used  (i.e. potentially outside of scop captured variables) and thereof there is a need especially carefully  behind a capture correctness.

3

Re: Lambda [and] and [=]

Hello, ffk, you wrote: ffk> Greetings to all. ffk> and so who can result arguments for [&=]? For functors given to algorithms, [and] - it is quite enough. All algorithms STL - pure functions i.e. lambdas will be destroyed to an output from area of visibility of locked variables. The algorithms I try to write also. One more plus [and] - it on what is not similar. [i] - brains try to interpret as operator []. Probably, in due course transits. Almost everywhere where I used lambdas (in decreasing order of frequency of occurrence): or [], or [and], or [this], or 1-2 local variables on value. [this] - often I use at connections to Qt th signals.

4

Re: Lambda [and] and [=]

Hello, N I., you wrote: NI> 1) when for different variables it is favourable to use different methods of capture (under the link and on value), NI> 2) when the lambda is used  (i.e. potentially outside of scop captured variables) and thereof there is a need especially carefully  behind a capture correctness. 3) when the garbage instead of variables is captured. Some times caught this bug in 2015 studios

5

Re: Lambda [and] and [=]

Hello, ffk, you wrote: ffk> I can not answer for myself on  a question: In what cases it is useful to use [and] and [=] instead of explicit  a dial-up of parameters? On my especially subjective taste, in any. Usage [and] and [=] is similar to assignment statement usage in conditions. Language allows, but to do it it is not recommended. Risk to capture something outside it is rather great, and such abbreviation is perfect itself does not justify. Certainly, and in that case when elements of the list of capture register explicitly, there can be errors, in particular at refactoring. But here on the guard there should be compiler warnings and-or code static analysis: in fresh versions clang already brought up-Wunused-lambda-capture, we will hope, as in remaining compilers the similar appears.

6

Re: Lambda [and] and [=]

Hello, ffk, you wrote: ffk> From pluses I have only one argument - very much laziness to register arguments, but it is an argument so-so since if the lambda uses   variables, it already any not the correct lambda, and if their only 1... 4 and to enumerate not a problem. Besides, we completely supervise that happens inside. On the other hand, if a lambda correct, i.e. very short what variables as are captured - and so it is obvious. Thus their explicit listing in the capture list in vain extends the code. Here in a similar case explicit listing can make a line too long: auto not_in_range = std:: find_if (d.begin (), d.end (), [=] (std:: int64_t value) {value <min_threshold || value> max_threshold;});

7

Re: Lambda [and] and [=]

Hello, ffk, you wrote: ffk> if the lambda uses   variables, it already any not the correct lambda, Such here a case still. Let the exterior interface demands from us not to let out an exception, and we add catch with conversion to return code: HRESULT SomeClass:: SomeMethod (BSTR param1, BSTR param2) {try {//...} catch (std:: bad_alloc) {return E_OUTOFMEMORY;} catch (...) {return E_FAIL;}} Also we admit catch units more and they it is more difficult.  sausage from catch is to be doubled no in each method. Traditionally such turn in . But at  there is a problem that a debugger on them do not resemble. There is such reception: HRESULT ExceptionFilter () {try {throw;} catch (std:: bad_alloc) {return E_OUTOFMEMORY;} catch (...) {return E_UNEXPECTED;}} HRESULT SomeClass:: SomeMethod (BSTR param1, BSTR param2) {try {//...} catch (...) {return ExceptionFilter ();} } But repeated throw it is inconvenient for debugging. There is a decision on the lambdas, deprived of this lack: template <class Callable> HRESULT ExceptionFilter (Callable f) {try {return f ();} catch (std:: bad_alloc) {return E_OUTOFMEMORY;} catch (...) {return E_UNEXPECTED;}} HRESULT SomeClass:: SomeMethod (BSTR param1, BSTR param2) {return ExceptionFilter ([and] {//...});} Yes, abusing . But all looks as the best decision for "exception firewall". And explicit listing of all arguments here out of place.

8

Re: Lambda [and] and [=]

Hello, Alexander G, you wrote: AG> AG> template <class Callable> AG> HRESULT ExceptionFilter (Callable f) AG> {AG> try AG> {AG> return f (); AG>} AG> catch (std:: bad_alloc) AG> {AG> return E_OUTOFMEMORY; AG>} AG> catch (...) AG> {AG> return E_UNEXPECTED; AG>} AG>} AG> HRESULT SomeClass:: SomeMethod (BSTR param1, BSTR param2) AG> {AG> return ExceptionFilter ([and] AG> {AG>//... AG>}); AG>} AG> AG> Yes, abusing . AG> But all looks as the best decision for "exception firewall". AG> And explicit listing of all arguments here out of place. Here it is better so: int exceptionFilter () {try {throw;} catch (std::exception&) {return 1;} catch (otherException&) {return 3;} catch (...) {return-1;}} try {functionThrowSomeException ();} catch (...) {return exceptionFilter ();}