[Rivet] Rivet boost::BOOST_FOREACH

[Andy Buckley]

Hi Andrii,

We are following the BOOST advice here:

http://www.boost.org/doc/libs/1_58_0/doc/html/foreach.html#foreach.introduction.making__literal_boost_foreach__literal__prettier

I have a feeling that this bug relates to the version of Boost you're 
using, in conjunction with more recent compilers. I recall that an 
updated boost.m4 script that we introduced in the recent version 2.3.0 
addresses the problem... or rather it detects that there will be a 
problem and requires a consistent GCC+Boost installation. Although my 
knowledge on that is vague -- maybe the Rivet author who made that 
update can correct me / give more detail.

The *real* solution will be to require and use the C++11 range-for 
construct instead of Boost's macro. This will also work a lot better for 
e.g. iterating over std::maps, which don't work well with the macro 
approach. And of course we can replace a lot (but not all, I think) 
Boost functionality in Rivet with C++11 standard features, so it's very 
appealing to many of us. But we don't feel that non-experiment HEP 
computing resources are yet in a state where we can make that C++11 
requirement without causing pain to many theory users.

For what it's worth, I'm currently using GCC 4.9.2 and Boost 1.55 and it 
works fine. In the pre-release testing that we do on CERN lxplus we use 
the system compiler but install our own 1.55 version of Boost.

Cheers,
Andy



On 04/08/15 13:05, Andrii Verbytskyi wrote:
> Dear Andy,
> I just tried to compile 2.* versions of Rivet on CentOS
> 7/gcc4.8.3/boost1.53.
> All those attempts failed, the compiler doesn't accept
> the Rivet code:
>
> ----------------------------------------------------------------------
>    CXX      libRivetCore_la-Run.lo
> In file included from ../../include/Rivet/Run.hh:5:0,
>                   from Run.cc:2:
> ../../include/Rivet/Tools/RivetBoost.hh:16:36: error: declaration of
> namespace 'boost::BOOST_FOREACH' conflicts with
>     namespace BOOST_FOREACH = foreach;
>                                      ^
> In file included from /usr/include/boost/foreach.hpp:89:0,
>                   from ../../include/Rivet/Tools/RivetBoost.hh:12,
>                   from ../../include/Rivet/Run.hh:5,
>                   from Run.cc:2:
> /usr/include/boost/foreach_fwd.hpp:56:1: error: previous declaration of
> namespace 'boost::BOOST_FOREACH' here
>   {
>   ^
> In file included from ../../include/Rivet/Math/MathUtils.hh:5:0,
>                   from ../../include/Rivet/Math/Math.hh:5,
>                   from ../../include/Rivet/Tools/Utils.hh:5,
>                   from ../../include/Rivet/Config/RivetCommon.hh:26,
>                   from ../../include/Rivet/AnalysisHandler.hh:5,
>                   from Run.cc:3:
> ../../include/Rivet/Math/MathHeader.hh:45:16: warning: 'Rivet::MAXINT'
> defined but not used [-Wunused-variable]
>     const double MAXINT = std::numeric_limits<int>::max();
> ----------------------------------------------------------------------
>
>
> It looks the reason is a well known (since 4 years!) BOOST bug.
> 1) Which compilers do you use for tests, i.e. with which compiler Rivet
> will work?
> 2) Has anyone tried to compile Rivet with (new)gcc?
> 3) Is it possible to drop that construction from Rivet? It looks it
> doesn't appear too often in the code and when it does the replacement is
> obvious.
>
>
> Best regards,
> Andrii
>
>
>
>
>
>
>
>
> On Fri, 2014-12-05 at 14:10 +0100, Andrii Verbytskyi wrote:
>> Hi,
>> yes, environment variables are working, however passing arguments via
>> environment variables is implicit way and implicit way is worse that
>> explicit. Also, in many cases environment variables will make things
>> less convenient or even defunct. A good example is using rivet
>> from a Makefile. One can say the same about using rivet in system() and
>> so on. Also, the way of setting environment variables depends on shell
>> --> less convenient usage of rivet even from shell.
>>
>>
>> Best regards,
>> Andrii
>>
>>
>>
>> On Fri, 2014-12-05 at 13:00 +0000, Andy Buckley wrote:
>>> Hi Andrii,
>>>
>>> Don't the environment variables work for these? --analysis-path is just
>>> syntactic sugar for those, and to be honest I was considering removing
>>> it to clean up the command-line interface!
>>>
>>> Andy
>>>
>>>
>>> On 05/12/14 12:44, Andrii Verbytskyi wrote:
>>>> Dear Andy,
>>>> here are some (hopefully useful) improvements for Rivet.
>>>>
>>>> In addition to --analysis-path I think it would be useful to have
>>>>
>>>> --ref-path, --info-path, --plot-path.
>>>>
>>>>
>>>> So here are the files with the changes. Please note that rivet should be
>>>> generated from rivet.in with a substitution of install paths.
>>>>
>>>> Best regards,
>>>> Andrii
>>>>
>>>
>>>
>>
>>
>
>


-- 
Dr Andy Buckley, Lecturer / Royal Society University Research Fellow
Particle Physics Expt Group, University of Glasgow