Re: Visual C++ Express won't compare object against float in std::upper_bound
"Ulrich Eckhardt" <eckhardt@satorlaser.com> wrote in message
news:dim2b4-dt7.ln1@satorlaser.homedns.org...
tron.thomas@verizon.net wrote:
[about use of std::upper_bound]
I added two member function to the class. One to compare if a Sample
was less than a float, and another to compare if a Sample was less
than another Sample. That solved the problem.
What I'm wondering now is why adding that additional members was
necessary, because on two other compilers the member wasn't
necessary. I'm curious as to whether then isn't a bug in one or more
of these compilers or their implementations of the STL.
It's non-normative, but take a look at the docs[1] at SGI's. It explicitly
states as a requirement that the iterator's value type must be the same as
the compared value's type. You are mixing an iterator over Samples with a
value of type float.
Right. More than one implementation of STL chose to relax this
requirement, allowing asymmetric comparisons in contexts where
the C++ Standard did not originally contemplate them. I know the
change has been proposed for the C++ Standard; whether it's
already in C++ 2003 or slated for the next version I don't
remember.
In any event, we meant to allow similar latitude, but I overlooked
the debugging check function at first. I templatized it with one
parameter for the types of both arguments, which disallows the
asymmetry. It now has separate template parameters for the two
arguments, but there were some VC++ versions that have the older
form.
In any case, it does make sense that if the algorithm allows mixing those
as
an extension, the less-than-comparable requirement must hold for all
combinations of them, i.e. you must be able to use both types freely on
both sides of the comparison.
Correct.
In case that isn't clear, the compiler will not use operator> and == to
form
an alternate form of operator< when that is not available!
Also correct. The library is meticulous about using only operator< for
all such comparisons.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com