octave-maintainers
[Top][All Lists]
Advanced

[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: Fri, 2 Oct 2020 14:11:05 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0

On 10/2/20 4:49 AM, Carlo De Falco wrote:

So, if it is now accepted to require a C++14 compatible compiler we should just document that and change the current configure test which looks for C++11 to look for C++14 instead. Otherwise, the use of "auto" for parameters should be abandoned. I'm not following in detail the discussion on this between jwe and Rik but it seems they are planning some way to work around this ...

We might still decide to require C++14 features but I also pushed the following changeset which avoids auto in the lambda expressions and moves the captured variables from the unwind_action objects to the lambda expressions where possible.

  http://hg.savannah.gnu.org/hgweb/octave/rev/445e5ac1f58d

In most cases, the need for "auto" goes away when the variables are captured in the lambda expression instead of being passed as arguments to the function generated by the lambda expression. So I meant to make that change first, followed by eliminating the remaining uses of "auto" in a separate changeset but forgot to split the change before pushing.

I also pushed a separate change to use the [=] capture default specification where possible:

  http://hg.savannah.gnu.org/hgweb/octave/rev/1ac5a76ae91d

If we still decide against using the [=] capture default for style reasons, it is easy to backout the changeset.

Please let me know if there are still problems with clang after these changes.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]