Re: STL and the SDK
NG wrote:
I recently installed the 2003 Server SDK and the Visual Studio 2005 C+
+ Express Edition. I tried to compile some STL code and I got
unanticipated errors. The code is below and it's fairly simple, I
define a simple test object class and a comparison functor. I then
create a vector of test objects and look for a match using the STL
equal_range algorithm. The compilation output is also included. I
successfully compiled the code with MinGW (gcc). The other strange
thing is the code compiled with the VC 6 compiler. In my searche to
find the error, I found a message that said the types for the
operator() in the functor must be the same. This does compile if
changed, but doesn't seem right considering that there are different
template types for the two parameters. Any help would be greatly
appreciated.
/**************Code
#include "stdafx.h"
#include <functional>
#include <algorithm>
#include <vector>
using namespace std;
class TestOb
{
public:
TestOb( int iMemInit ):m_iMem(iMemInit){}
TestOb( const TestOb & object ):m_iMem(object.m_iMem){}
TestOb& operator=( const TestOb & object ){
m_iMem = object.m_iMem;
return *this;
}
int GetInt(){
return m_iMem;
}
private:
int m_iMem;
};
class OB_COMP : public binary_function<int,TestOb,bool>
{
public:
bool operator()(int iTest, TestOb& rOb){
return iTest<rOb.GetInt();
}
bool operator()(TestOb& rOb, int iTest){
return iTest<rOb.GetInt();
}
They should both be const members (though that isn't your problem).
Additionally, you might want to define:
bool operator()(TestOb& lhs, TestOb& rhs) const;
bool operator()(int lhs, int rhs) const;
};
int _tmain(int argc, _TCHAR* argv[])
{
vector<TestOb> vObjects;
vObjects.push_back( TestOb(1) );
vObjects.push_back( TestOb(2) );
vObjects.push_back( TestOb(3) );
pair<vector<TestOb>::iterator,vector<TestOb>::iterator> prSearch =
equal_range( vObjects.begin(),vObjects.end(),2, OB_COMP() );
return 0;
}
The code is legal under the 1998 and 2003 standards I think, though the
wording in those standards is a bit odd. The following defect clarifies
what should really work:
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#270
I think the compiler error is due to over-zealous debug checks that are
confirming that OB_COMP can compare two TestOb objects, and defines a
strict weak ordering on TestOb objects.
Tom