[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: error with d28016d16e9a (change to jsonencode.cc)
From: |
John W. Eaton |
Subject: |
Re: error with d28016d16e9a (change to jsonencode.cc) |
Date: |
Thu, 1 Oct 2020 13:57:36 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 |
On 10/1/20 1:24 PM, Rik wrote:
In one sense, this is easy to resolve. Instead of using the keyword
"auto" just specify the exact type of the underlying variable. However,
the compiler really should be able to handle this construct. Could you
try 'g++ --version'? And is it really GNU g++ or is this a soft link to
clang?
It looks like accepting auto in this context is a C++14 feature.
Also, I noticed we can simplify some things. The unwind_action allows
writing things like
int val; // Will be captured by the unwind_action objects below.
unwind_action act ([val] () { use_val (val); })
or
unwind_action act ([] (int val) { use_val (val); }, val);
in the first case, VAL is captured directly by the lambda expression and
is not passed as an argument to the function it creates. In the second,
the unwind_action object captures the value and passes it as an argument
to the function that the lambda expression creates.
Both forms have the same ultimate effect, but the second is useful when
you want to capture a value that is not directly available as a variable
and can't be captured by the lambda. For example, in
octave::unwind_action restore_warning_state
([] (const octave_value_list& old_warning_state)
{
set_warning_state (old_warning_state);
}, set_warning_state ("Octave:classdef-to-struct", "off"));
the warning state is only accessible through function calls in this
context, so we can't capture it directly in the [] part of the lambda
expression, but in other places, we could write
octave::unwind_action close_outfile
([outfile] () { std::fclose (outfile); });
instead of
octave::unwind_action close_outfile
([] (const auto file_ptr) { std::fclose (file_ptr); }, outfile);
Using either form should work but maybe we should use the direct lambda
capture form when the values we need to capture are variables accessible
in the current scope?
jwe
- error with d28016d16e9a (change to jsonencode.cc), Benjamin Abbott, 2020/10/01
- Re: error with d28016d16e9a (change to jsonencode.cc), Rik, 2020/10/01
- Re: error with d28016d16e9a (change to jsonencode.cc), Carlo De Falco, 2020/10/01
- Re: error with d28016d16e9a (change to jsonencode.cc),
John W. Eaton <=
- Re: error with d28016d16e9a (change to jsonencode.cc), Rik, 2020/10/01
- Re: error with d28016d16e9a (change to jsonencode.cc), John W. Eaton, 2020/10/01
- Re: error with d28016d16e9a (change to jsonencode.cc), Rik, 2020/10/01
- lambda expressions (was: Re: error with d28016d16e9a ...), John W. Eaton, 2020/10/02
- Re: lambda expressions (was: Re: error with d28016d16e9a ...), Rik, 2020/10/06
Re: error with d28016d16e9a (change to jsonencode.cc), Benjamin Abbott, 2020/10/01
Message not available
Re: error with d28016d16e9a (change to jsonencode.cc), Carlo De Falco, 2020/10/01