[Rivet] bug: RivetSTL conflicts with LHAPDF includes

[Andy Buckley]

Hi Dmitry,

Thanks for letting us know. I have moved the named functions to the 
Rivet namespace now, which is hopefully enough to make the resolution 
unambiguous.

Andy


On 26/11/15 13:13, Dmitry Kalinkin wrote:
> Dear Rivet developers,
>
> I’ve encountered a bug that prevents me from using both Rivet and LHAPDF includes in one file:
> % cat test.cpp                                                                                                                                                                                                      :(
> #include <Rivet/AnalysisHandler.hh>
> #include <LHAPDF/LHAPDF.h>
>
> % gcc test.cpp `rivet-config --cppflags` `lhapdf-config --cppflags`
> In file included from lhapdf/6.1.5/include/LHAPDF/Info.h:10:0,
>                   from lhapdf/6.1.5/include/LHAPDF/PDFInfo.h:10,
>                   from lhapdf/6.1.5/include/LHAPDF/PDF.h:10,
>                   from lhapdf/6.1.5/include/LHAPDF/LHAPDF.h:14,
>                   from test.cpp:2:
> lhapdf/6.1.5/include/LHAPDF/Utils.h: In function 'std::__cxx11::string LHAPDF::operator/(const string&, const string&)':
> lhapdf/6.1.5/include/LHAPDF/Utils.h:111:30: error: call of overloaded 'contains(std::__cxx11::string&, const char [3])' is ambiguous
>       while (contains(rtn, "//"))
>                                ^
> lhapdf/6.1.5/include/LHAPDF/Utils.h:70:15: note: candidate: bool LHAPDF::contains(const string&, const string&)
>     inline bool contains(const std::string& s, const std::string& sub) {
>                 ^
> In file included from rivet/2.4.0/include/Rivet/Config/RivetCommon.hh:45:0,
>                   from rivet/2.4.0/include/Rivet/AnalysisHandler.hh:5,
>                   from test.cpp:1:
> rivet/2.4.0/include/Rivet/Tools/RivetSTL.hh:95:15: note: candidate: bool std::contains(const string&, const string&)
>     inline bool contains(const string& s, const string& sub) {
>                 ^
> <and so on>
>
> This also reproduces with clang.
>
> I’ve tried to isolate the issue, but couldn’t get to the root of it. There extension of std:: in RivetSTL.hh is questionable and this is one possible point for fix. On the other hand LHAPDF/Utils.h could be fixed as it has "using namespace std;”, but for some reason replacing it with explicit "std::" doesn’t solve the problem. It seems to me that the fastest way to tackle this would be to fix Rivet (e.g. wrap mili functions into mili:: as done in https://bitbucket.org/fudepan/mili/src/a8ade229696cfae66f55121222dd95594cfae276/mili/mili.h?at=default&fileviewer=file-view-default#mili.h-32 ).
>
> Cheers,
> Dmitry
> _______________________________________________
> Rivet mailing list
> Rivet at projects.hepforge.org
> https://www.hepforge.org/lists/listinfo/rivet
>


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