[Rivet] C++11 plan for Rivet

[Holger Schulz]

On 17/03/16 09:19, Andy Buckley wrote:
> Hi all,
>
> I'm currently hacking together a prototype physics object smearing 
> system for Rivet 2.5 or 2.6, to be beta-tested with the BSM 
> experimental groups and re-casters. No capitulation: we will continue 
> to require unfolded "proper" measurements, but there is BSM demand for 
> Rivet and they will not bite unless we can provide at least some 
> simple machinery for efficiency curves.

I completely agree now that the ATOM guys have essentially decoupled 
their efforts from Rivet.
I did something like that in my ATLAS analysis for random removal of 
tracks based on track
reco efficiency and I know that there is demand to have that in rivet, too.



>
> The way I'm designing it can all be done with Boost features, but once 
> again it's stuff that is part of the core language in C++11 and using 
> the less-standard Boost implementations feels like going in the wrong 
> direction. Also, we are starting to see submitted analyses which use 
> C++11 features, and it both feels unnecessarily restrictive on our 
> "clients" and is extra work for us to have to revert that code to C++98.
>
> So I would like us to make the switch to mandatory C++11 building of 
> Rivet in the next couple of 2.x releases. This would also help us to 
> reduce the currently huge number of "paradigm shifts" scheduled (for 
> lack of imagination) on v3.0.
>
> There is one major sticking point, in the form of FastJet. While C++11 
> compatible, it makes use of auto_ptr and exposes that in its public 
> headers, meaning that anyone compiling a Rivet analysis in C++11 mode 
> gets a terminal output dominated by FJ auto_ptr deprecation warnings. 
> There seems to be no way in GCC to disable these warnings -- or does 
> someone know of one? So I think we need to put a bit of pressure on 
> FastJet to make a non-complaining release; I already did this ~6 
> months ago and was told that they are working on a major new 
> development, but it has not appeared and the issue is more urgent now 
> (I don't know what the experiments are doing re. this). So I'll prod 
> them again and hopefully we'll be able to make this switch in Rivet 
> 2.5 or 2.6.

We can just ask again, maybe point them to this forum:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59325

Holger
>
> Thoughts and suggestions welcome as always...
>
> Andy
>