Fix C++11 deprecation warnings

[haampie]

No description provided.

[rkaminsk]

Not sure what @BenKaufmann will say to this. Currently, clasp still compiles using C++98 if build without threads. The patch makes it incompatible. Another easy route would be to simply spell out the operators. A quick grep shows that there are further occurrences of std::mem_fun.

With C++11, one can also remove the whole std::mem_fun business and use lambda's.

[haampie]

Oh, I thought this was C++11... Shouldn't CMake set the C++ standard to 98 then? Ah, I see C++11 is only conditionally required...

Probably got confused because clingo is setting a newer C++ standard 🙃

[BenKaufmann]

@haampie Thank you for the PR. I understand and appreciate the motivation. However, I disagree with the concrete change set.

As @rkaminsk mentioned, clasp is still a C++98 code base at its core. C++11 is only required when building clasp with multi-threading enabled. This requirement was added in clasp 3.3.0 since it allowed us to drop the dependency to Intel's TBB library. No other modernization happened at this point though.

In general, the plan for the future is to modernize clasp - but this should be a strategic/holistic change targeting at least C++17 or 20. It should also be tied to a new major version.

For now, I would suggest to:

• replace std::mem_fun with std::mem_fn in src/parallel_solve.cpp as this file explicitly depends on C++11 (or later)
• disable deprecation warnings on the libclasp target in src/CMakeLists.txt
• mark clasp/util/misc_types.h as "system header" so that it does not generate warnings when included
• (optionally) force C++98 mode in CMakeLists.txt if CLASP_BUILD_WITH_THREADS is false

I created a corresponding branch and with these changes, I could build both clasp and clingo without the deprecation warnings. Please let me know whether this would also work for you.

Finally, please observe that all development happens in the "dev" branch and therefore PRs should be opened against this branch.

[rkaminsk]

@BenKaufmann what about replacing std::mem_fun with explicit operators. Sure it's a little more verbose but we have a problem here because std::mem_fun is going to be removed. Like this it would continue to compile nicely with newer compilers (that no longer support C++98/not sure if there are/will be any).

[BenKaufmann]

@rkaminsk I'm not sure I understand your concern here. Yes, compilers are allowed to remove std::mem_fun in >= C++17. However, std::mem_fun is not used in a header and the library itself is compiled in C++11 mode, so as long as compilers support a mode-switch, it should be fine.

EDIT: Ah, sorry. Missed your edit.

[haampie]

I'm happy with @BenKaufmann's suggestions, my goal was to get rid of the noisy warnings but I missed that clasp and clingo have a different minimal c++ standard.

Feel free to close 🙃

[rkaminsk]

@rkaminsk I'm not sure I understand your concern here. Yes, compilers are allowed to remove std::mem_fun in >= C++17. However, std::mem_fun is not used in a header and the library itself is compiled in C++11 mode, so as long as compilers support a mode-switch, it should be fine.

EDIT: Ah, sorry. Missed your edit.

I am fine with your update. Let's keep it like this. Compiler developers are typically very conservative anyway. It's just that I personally would have chosen to make the code "forward" compatible.

[BenKaufmann]

It's just that I personally would have chosen to make the code "forward" compatible.

Ok, I'll look into that. For now, I close this PR with my changes merged to dev.