Re: Visual C++ Express won't compare object against float in std::upper_bound

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

On Feb 21, 6:24 am, "John Carson" <jcarson_n_o_sp_...@xxxxxxxxxxxxxxx>
wrote:
"Igor Tandetnik" <itandet...@xxxxxxxx> wrote in message

news:%239O8SjbVHHA.4380@xxxxxxxxxxxxxxxxxxxx

"John Carson" <jcarson_n_o_sp_...@xxxxxxxxxxxxxxx> wrote in message
news:%233YwSvaVHHA.972@xxxxxxxxxxxxxxxxxxxx
I noticed that too. However, the issue is not whether the member and
non-member operators have the same order, but what order the
upper_bound function requires.

Both, under VC2005 with iterator debugging. In fact, I believe you
need all three: Sample/Sample, Sample/float, float/Sample. The
debugging code checks that the predicate is in fact a proper
ordering, by comparing the two arguments both ways.

Yes, you are right. Defining all three makes it work using the original code
in main. Specifically:

namespace
{
class Sample
{
public:
Sample (float value, float position) : m_value(value),
m_position(position)
{}

float GetValue() const { return m_value; }
float GetPosition() const { return m_position; }

friend bool operator<(const Sample & lhs, float position);
friend bool operator<(float position, const Sample& rhs);
friend bool operator<(const Sample& lhs, const Sample& rhs);
private:
float m_value;
float m_position;
};

bool operator<(const Sample& lhs,float position)
{
return lhs.m_position < position;
}
bool operator<(float position, const Sample& rhs)
{
return position < rhs.m_position;
}
bool operator<(const Sample&lhs, const Sample& rhs)
{
return lhs.m_position < rhs.m_position;
}

typedef std::vector<Sample> SampleBuffer;
typedef SampleBuffer::iterator SampleIterator;

}

--
John Carson

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.

What is the reason the additional members were needed for the
Microsoft compiler and not for the GNU or Borland compilers?

.

Relevant Pages