Re: [csmith-dev] c++11

On Mon, Apr 4, 2016 at 8:12 AM, John Regehr <regehr@cs.utah.edu> wrote:

FWIW, The LLVM Project switched to C++11 (or the subset supported by a
variety of compilers (Clang, GCC, and MSVC) with a horizon of about a
couple of years (
http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features
). Seems to be doing OK so far.

Exactly. I've found writing LLVM-styled C++11 to be pretty pleasant, and I'm skeptical that there are very many people for whom running a reasonably recent version of GCC, LLVM, or MSVC is a hardship.

Hi John! I haven't looked at the Csmith codebase in years and years, but I still lurk this list.

My two cents is: C++11 is not an untested or uncertainty-fraught language (not like C99 was ten years ago, for example). However, introducing C++11'isms into your codebase will probably limit its audience.

My impression is that LLVM (and Clang) can get away with requiring C++11, because they provide cross-compiler support by definition. You don't need to compile LLVM's C++11 codebase with some obscure non-C++11 compiler, because you can compile it with Clang on a modern Linux system, produce a cross-compiler for your obscure platform, compile LLVM with the cross-compiler, etc.

My (possibly obsolete) impression is that Csmith is not a cross-compiler; the Csmith binary and the compiler-under-test must both be able to run on the same target-platform-under-test. This means that if you want to use Csmith to test a C compiler for Platform X, you must also be in possession of a C++03 compiler for Platform X (or else you must be in possession of a Platform X emulator). And the question under discussion is, "should you heighten that requirement to 'you must be in possession of a C++11 compiler for Platform X (or else a Platform X emulator)'?".

I'd say "no, you shouldn't heighten that requirement unless it buys you some measurable advantage in return," and I'm not hearing any specific advantages. (*)

However, a good and harmless first step could be to add a USE_CXX11 Makefile flag that adds "-std=c++11" to the gcc command line. C++11 is almost 100% backward-compatible with C++03, so allowing people to choose to compile Csmith in C++11 mode would be harmless, and would allow you to measure whether you're gaining anything from C++11 besides style points. It's also a camel's nose inside the tent for when you have this same discussion next year. ;)

Speaking of which, you could improve the code by following "Modern C++" idioms even while writing in the common subset of C++03 and C++11. For example, I opened a completely random file — src/CFGEdge.cpp — to check the style, and literally the first thing I see is

CFGEdge::CFGEdge(const CFGEdge &edge)
: src(edge.src),
dest(edge.dest),
post_dest(edge.post_dest),
back_link(edge.back_link)
{
// nothing else to do
}

CFGEdge::~CFGEdge(void)
{
}

This code doesn't follow the "Rule of Zero". If it did, you'd get fast move semantics in C++11 for free, just by compiling with that USE_CXX11 flag... but you'd preserve C++03 compatibility as well for those obscure Platform Xs.

Basically you ought to do something like this:

https://github.com/Quuxplusone/Homeworlds/commit/671a3961dbab6f2f67d8a2b225d6fc71dc694f89

throughout the Csmith codebase. Bringing a codebase into the 2010s doesn't necessarily mean using C++11 features; it can mean simply avoiding this kind of pessimization.

FYI, that Homeworlds commit above corresponded to a 5% improvement in wall-clock time for my (C++11) benchmarks. So the "Rule of Zero" does indeed produce measurable benefits; it's not just abstract code-style stuff.

–Arthur

(*) — I can imagine specific advantages to C++11, such as "we can use unique_ptr and shared_ptr to eliminate memory leaks and manual reference-counting", or "we can replace 600 lines of Win32 threading code with 10 lines of std::thread", but I don't know if those are things that apply to the Csmith codebase, so I'm pessimistically assuming that they're not.