redefine equlity of pairs

[sbrohee]

Hi everybody,

In standard C++, two pair objects (pair <int, int>) are equal when the first and the second member of the pair are equal. Would it be possible to redifine the pair so that to pairs would be equal when only the second terms are equal?

Thanks a lot for your help,

[Ancient Dragon]

Write your own pair class and implement the == operator any way you want.

[sbrohee]

Yes, I thought about this solution. Do you really think this is the easiest way?

[Ancient Dragon]

Well you obviously can't change the original pair class, so subclass it and do your own thing.

[sbrohee]

OK ... thanks a lot! I will go in that direction then.

[mike_2000_17]

There is _maybe_ a tricky way to do this. Since the == operator is not required to be inside the class definition of pair, you could implement it outside of it. Now the problem will arise with the two conflicting functions: the original (somewhere in the std namespace) and your own. Now, it's all a matter of namespacing. If you define your function in the global namespace, the compiler will look for the == operator and find it in the std namespace before it reaches the global namespace and your overloaded version will never be called. Now, on the opposite, if you put that overloaded operator == in a namespace below the std namespace like this:

namespace std {
  namespace my_dirty_hack {
     template<typename T1, typename T2> 
     bool operator ==(const pair<T1,T2>& p1,const pair<T1,T2>& p1) {
       return (p1.second == p2.second);
     }; 
  };
};

Then, by being VERY VERY CAREFUL with where you call the == operator from, you might just be able to get away with it. This uses the idea that compilers look for the overload operator or function starting from the namespace where it was called and then move up the namespaces. I'm not even sure if this can actually be done, because it is very tricky, and I don't know how to avoid getting the compiler to go crazy over this hack.

Another dirty hack to accomplish this is to do a template specialization of pair. If, in your case, this is only needed for one type of pair (say "pair<int,int>") and it is localized to only one cpp file, and in that cpp file you never use another pair<int,int> type for which you don't want that new operator== overload, then, you might just be able to provide a template specialized operator overload for the pair<int,int>, like this:

namespace std {

  template <>
  bool operator ==(const pair<int,int>& p1,const pair<int,int>& p2) {
    return (p1.second == p2.second);
  };

};

But I don't think it's worth the trouble or the risk of mixing the behaviour of the two different operators. I would absolutely not recommend doing that. I think just making your own pair class, whether replacing pair, deriving from pair, encapsulating pair, templating, or even MACRO-wrapping it somehow, will all be easier, clearer and safer.

[mrnutty]

Do you really need to use the "==" operator. Can you settle for something like this :

typedef pair<int,int> IntPair;
bool hasEqualSecond(const IntPair& lhs, const IntPair& rhs){
  return lhs.second == rhs.second;
}
//....
if(hasEqualSecond(p1,p2)){ /*do something */ }

[sbrohee]

> Mike
I thank you a lot for your help. As you could maybe already conclude it from my question, I am a real noob (at least in C++) and my question was very naive (I really thought this would be easier), I certainly did not intend to do things that might make the compile crazy! Thank you for your solution which I will not follow as all of you seem not to recommend it.

> firstPerson
I really need to overload == because in my program I play with a std::set of pairs. When I add a pair in the set, I want it to replace the pair having the same second term (if any). At the moment, in my small program, I add the pair (1st instruction) and then I remove the old one (second instruction) ... which is far from being efficient.
Pairs are suited structure in my case (at least I think so), as in my set, I want them to be sorted by the first term.

Thanks a lot again to all of you who contributed to this thread. I am learning everyday!