[Rivet] C++11 plan for Rivet

[Frank Siegert]

>> To see whether we really use gcc 4.8 functions, I disabled the
>> configure checks, and the only place where compilation fails with 4.7
>> is the map::emplace in Logging.cc and the special normalize functions
>> in MC_MET.cc. Don't know whether it's possible/worth replacing these
>> two and run it through the test suite. Thus we would have a Rivet
>> version which still builds with 4.7 in the short term while that's
>> still used in the community?
>> This is of course "only" a social argument, which runs contrary to
>> David's strong opinion about not caring about backwards compatibility,
>> which I can understand from a programmer's point of view as well.
>
> Thanks for doing the digging. Useful to know that it only fails on those...
> they are obviously work-aroundable.
>
> I'm surprised that it fails on those "special normalize" functions, since
> they're just using initializer list syntax, not variadic templates or
> anything similarly funky. Hmm. Maybe that version needs an extra set of
> braces to convince the compiler that it knows what's going on.
>
> But that serves as an illustration of why this is difficult... once we start
> supporting partial implementations of C++11, we have to be super-careful
> that anything we add is not just valid C++11, but valid within the partial
> support and bugginess of GCC 4.7. Yikes.
>
> So we could do this, and I'm sure we *will* do it if necessary, but my gut
> feeling is that we're better off making a clean break and fully using all
> (nice) new language features, specifically because the experiments can still
> use Rivet via Grid-distributed standard releases, just not the same ones as
> used in sample production. Given that people don't use the sample production
> releases for analysis, either, this doesn't strike me as a major obstacle,
> but maybe I'm biased.

I agree that it's not urgently necessary (yes, in ATLAS we can run
Rivet with a newer release). I was just selfishly thinking about
people in a situation like me: working mainly with gcc 4.7 based
software and not wanting to have two sets of local installations of
generator software on each cluster, one for use in official ATLAS
stuff (compiled with gcc 4.7), and one for running through Rivet
(compiled with gcc >=4.8). But I guess I'll just stick to Rivet <2.5
as long as that is the situation.
I should have shouted when this was discussed on the list before Rivet
2.5, but didn't see these implications back then yet.

Cheers,
Frank