On 5/4/20 4:16 PM, Thibaut Cuvelier wrote:
> That's a lot of emails :)!
>
> I hereby grant permission to use my contributions to LyX under the GPL
> license version 2 or later.
Thanks.
> Code with std::unary_function is still valid in C++11, but became
> deprecated in this version (and deleted with C++17). VC has not
> exactly been known for standards compliance in the past, but they
> improve: I could not compile LyX in C++11 or C++14 modes due to some
> features being only available starting with C++17, even though that
> sounds strange.
LyX is meant to be compilable with C++11. Do you know what caused the
problems? Whatever it is, it should be fixed.
> I changed the code to use more often the ::find() functions and
> similar. In TextClass, I had to add new methods. That's the included
> patch, which replaces two of the previous patches.
Thanks. The use of find() is great. Can you check if the attached works
for you? I just don't like the lambdas, which are hard for me to read. I
can fix the other cases like this if it does work.
Riki
On Mon, 4 May 2020 at 20:58, Richard Kimberly Heck <rikih...@lyx.org
<mailto:rikih...@lyx.org>> wrote:
>
> On 5/4/20 2:09 PM, Jean-Marc Lasgouttes wrote:
> > Le 04/05/2020 à 06:05, Thibaut Cuvelier a écrit :
> >> Dear list,
> >
> > Dear Thibaut,
> >
> >> During my work on DocBook (which started at
> >> www.lyx.org/trac/ticket/8444
> <http://www.lyx.org/trac/ticket/8444>
> <http://www.lyx.org/trac/ticket/8444>),
> >> I switched to Visual C++ 2019 as a compiler. The only way I
> found to
> >> make it compile large parts of LyX was to switch to recent C++
> >> standards, so that all features are available. Unfortunately, some
> >> deprecated parts of C++ have been removed in the latest versions of
> >> the standard… These changes are probably not required for now with
> >> other compilers, but some form will be required in the future when
> >> switching to newer C++ versions.
> >
> > Thanks for the patches. As you mentioned later, the boost part
> should
> > be done by upgrading boost. The new includues are OK.
> >
> > Concerning the "modern" C++ contructs, I am all for removing helper
> > casses that we had, but I would not describe lambda functions as
> > something that one may like to read.
>
> I was just working on this, for the same reason: All the lambdas
> threaten to make the code unreadable, and hard to maintain (as so many
> of them declare the same function). But what we can do is:
>
> // Takes the argument d and returns a (pointer to a) function that
> returns whether
> // some Branch b has the name d.
> std::function<bool (Branch const &)> BranchNamesEqual(docstring
> const & d)
> {
> return [d](Branch const & b){ return b.branch() == d; };
> }
>
> I think that should work in C++11? Similarly in other cases.
>
> I'm happy to do these fixes if the idea seems right.
>
> Riki
>
>
> --
> lyx-devel mailing list
> lyx-devel@lists.lyx.org <mailto:lyx-devel@lists.lyx.org>
> http://lists.lyx.org/mailman/listinfo/lyx-devel
>
>From 90746cd5c975b92535120f46a522817af4cc341b Mon Sep 17 00:00:00 2001
From: Richard Kimberly Heck <rikih...@lyx.org>
Date: Mon, 4 May 2020 19:08:12 -0400
Subject: [PATCH] Replace functor in BranchList
---
src/BranchList.cpp | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/src/BranchList.cpp b/src/BranchList.cpp
index 9c0078b316..f125e80177 100644
--- a/src/BranchList.cpp
+++ b/src/BranchList.cpp
@@ -27,20 +27,12 @@ namespace lyx {
namespace {
-class BranchNamesEqual : public std::unary_function<Branch, bool>
+// Takes the argument d and returns a (pointer to a) function that
+// returns whether Branch b has the name d.
+std::function<bool (Branch const &)> BranchNamesEqual(docstring const & d)
{
-public:
- BranchNamesEqual(docstring const & name)
- : name_(name)
- {}
-
- bool operator()(Branch const & branch) const
- {
- return branch.branch() == name_;
- }
-private:
- docstring name_;
-};
+ return [d](Branch const & b){ return b.branch() == d; };
+}
} // namespace
--
2.21.1
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
