[Rivet] inRange trouble

[Andy Buckley]

On 22/09/11 10:55, Hendrik Hoeth wrote:
> Thus spake Andy Buckley (andy.buckley at ed.ac.uk):
>
>>> So, what do we do? Right now the function is templated, so that the
>>> first three arguments have the same type. Adding an inRange(double,<T>,<T>)
>>> won't work, because it introduces an ambiguity. Getting rid of the
>>> templates altogether means we need to introduce a loooong list of
>>> inRange functions.
>>
>> Do we really? If we have an explicit (int, int, int) and a (double,
>> double, double), won't implicit conversion do the rest?
>
> ATLAS_2011_I919017.cc:780:42: error: call of overloaded 'inRange(double, int, int)' is ambiguous
> ATLAS_2011_I919017.cc:780:42: note: candidates are:
> ../../include/Rivet/Math/MathUtils.hh:108:15: note: bool Rivet::inRange(double, double, double, Rivet::RangeBoundary, Rivet::RangeBoundary)
> ../../include/Rivet/Math/MathUtils.hh:132:15: note: bool Rivet::inRange(int, int, int, Rivet::RangeBoundary, Rivet::RangeBoundary)

Pah, bad guess on my part then. Yep, we'll have to rewrite Rivet in 
Python, or at least some language that understands that ints, doubles, 
etc. are all different types of *number*.

So what was wrong with inRange(<T1>,<T2>,<T3>) and specialising on int, 
int, int -- you said "ambiguity"?

C++ is such Fun, isn't it?! ;)

Andy

-- 
Dr Andy Buckley
SUPA Advanced Research Fellow
Particle Physics Experiment Group, University of Edinburgh

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.