[Rivet] C++11 plan for Rivet

[Frank Siegert]

Hi all,

I want to revive this thread for one aspect, that has only become
clear to me now that people are starting to use the C++11 Rivet in
practice.

When other programs (e.g. Sherpa) are linking to Rivet, they typically
include AnalysisHandler.hh, which already uses C++11 features. So
users compiling those programs with gcc<6 will already have to make
sure that they export CXXFLAGS=-std=c++11 during that compilation. Is
there any simple and reasonable way to avoid this by making the
exposed interface C++98 compatible?

On the same note, I realised that we should document on the website
which gcc versions we support (so far this is neither in the 2.5.0
release announcement, nor on the Getting Started page, or did I miss
it?). For example: are we happy with >=4.7 as still used in
experiments a lot, or do we need the features introduced in 4.8
(https://gcc.gnu.org/projects/cxx-status.html#cxx11). Since we are one
of the first projects in the MC landscape to switch to a requirement
of C++11, we should provide the users with some guidance, and also
mention that they have to export CXXFLAGS=-std=c++11 when compiling
with an older compiler.

Cheers,
Frank

On 24 March 2016 at 11:55, Andy Buckley <andy.buckley at cern.ch> wrote:
> Yes, I agree. This should be an opportunity to clean up and make our API
> more expressive, not to introduce more fallbacks and complexity.
>
> Andy
>
>
>
> On 24/03/16 10:27, David Grellscheid wrote:
>>
>> Hi Andy,
>>
>> I'm all for the transition to C++11. But if we do it, I vote for a hard
>> switchover. No backwards compat flags, #ifdefs falling back to Boost,
>> etc. Once a function is converted, it stays that way. We should assume a
>> fully-compliant C++11 compiler and not have to worry about use of
>> individual features, and when they started being supported by which
>> version of gcc.
>>
>> See you,
>>
>>    David
>>
>>
>>
>> On 23/03/2016 22:19, Andy Buckley wrote:
>>>
>>> On 17/03/16 10:27, Holger Schulz wrote:
>>>>
>>>>
>>>>
>>>> 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.
>>>
>>>
>>> Somehow I was interested enough in this to spend a bit of time hacking a
>>> start together. Here it is:
>>>
>>>
>>> https://rivet.hepforge.org/hg/rivet/file/tip/include/Rivet/Projections/SmearedParticles.hh
>>>
>>>
>>>
>>> https://rivet.hepforge.org/hg/rivet/file/tip/include/Rivet/Projections/SmearedJets.hh
>>>
>>>
>>>
>>> (Connoisseurs of borderline-evil code may like to note how the function
>>> hash for projection comparison is being done ;-) But no worse than what
>>> you need to do to use POSIX dlsym... aka the evil_cast in AGILe's module
>>> loader.)
>>>
>>> And here's how the SmearedJets looks in action in an analysis:
>>>
>>> FastJets fj(FinalState(Cuts::abseta < 5), FastJets::ANTIKT, 0.4);
>>> SmearedJets sj(fj, JET_EFF_ONE, JET_SMEAR_IDENTITY);
>>>
>>> Ok, those are do-nothing standard perfect efficiency and smearing
>>> functions, but the principle works. I'm populating a file with a few
>>> real efficiency and smearing functions... but they will strongly benefit
>>> from going to mandatory C++11 so we can use the new random generator
>>> machinery. And here's another C++11 killer feature for this use-case --
>>> inline lambda functions:
>>>
>>> SmearedJets sj(fj,
>>>                 [](const Jet& j) { return 1 - exp(-j.pT()/(10*GeV)); },
>>>                 [](const Jet& j) { return j; });
>>>
>>> I think this stuff makes a pretty good case for going to C++11 with the
>>> addition of this feature... and then gradually converting lots of our
>>> internal Boost and hackery to use the much nicer new language features
>>> instead.
>>>
>>>>> 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
>>>
>>>
>>> Did that: thanks for the link :-) And the timing was good: FastJet 3.2.0
>>> is out now and at the last minute they removed auto_ptr from fjcore and
>>> added a configure-time option to disable the auto_ptrs in the main FJ
>>> interface.
>>>
>>> And it looks like LCG can be persuaded to build their FJ 3.2.0
>>> installations using that flag, so once there is such a bundle to play
>>> with, we can make a mandatory C++11 release. Which I would like to use
>>> for beta-testing the new smearing features with interested parties.
>>>
>>> Cheers,
>>> Andy
>>>
>
>
> --
> Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
> Particle Physics Expt Group, University of Glasgow
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet