   Global Operator== Or Member Operator==
  Hello :)I am looking at using the STL vector in some of my code, and the SGI version (which I am currently looking at), states (in regards to the operator==) "Tests two vectors for equality. This is a global function, not a member function."I'm wondering why they have made it global and not a member function?In the past I have made operator== a member function, and I have never had any problems.  Looking around the Internet, I can't find anything that say's if it's a good thing or a bad thing (it's probably neither), but what are the benefits?Hope this is a simple one for you guys ;)   
  As I understand it, its a matter of choice.  You can use a global function if everything that determines the uniqueness of an object is publicly accessible.  Otherwise it has to be a member to look at private state.  Does that help?   ;Quote:Original post by legalizeYou can use a global function if everything that determines the uniqueness of an object is publicly accessible.Unfortunatly, thats not always true.  In the case of Boost smart pointers (I've been having a root around in other template libraries for a solution), they declare the operator== as a friend function, so when it is defined in the global scope, it can access the internals of the params passed :;  Yeah, you can have a friend function that can reach into your pants and grope around to its satisfaction, but I don't see why that would be preferred over having a member function.  There might be some difference beyond preference, but I don't know what it is off the top of my head."friend" functions and classes feel like a C++ code smell to me.   ;  On the surface I would def. agree with you, but from my further rootings into other STL style implementations, they all have global operator== functions.So I'm wondering there must be a reason out there for this decision :)   ;  Member operators behave badly with respect to implicit conversions, in particular for member operators no conversions will be applied to the left hand side operand but conversions will be applied to the right hand side operand.// Examplestruct foo{    foo(int i) { }};int main(){    foo x(1);    // if foo had a member operator== this would cause a compiler error    1 == x;    // but this wouldn't    x == 1;    // both will work fine with a non-member operator==};Prefer non-member non-friend functions to member functions.andDeclare non-member functions when type conversions should apply to all parameters.   ;Quote:Original post by legalize"friend" functions and classes feel like a C++ code smell to me.In my experience, they are rather a deodorant for the smelliness of C++ :)   ;  Ok, the points made are all valid, and I can see exactly why they would be used, but in a vector?Quote:Original post by Julian90Member operators behave badly with respect to implicit conversions, in particular for member operators no conversions will be applied to the left hand side operand but conversions will be applied to the right hand side operand.*** Source Snippet Removed ***Good point, but doesn't that make no sense when working with an STL vector.  When would I ever want to check that anything other than a vector of the same type is equal to the current one?  If the two vectors are not the same type, they should not be compared.Surely this is making the global == more unobvious about how it should behave.Quote:Original post by DeventerPrefer non-member non-friend functions to member functions.andDeclare non-member functions when type conversions should apply to all parameters.Interesting link, and I had a good read last night.  But again I have some slight problems when put into the scope of a STL vector.Non-member, non-friend functions may increase encapsulation (encapsulation of data but not behaviour!), but the point of a vector it to work with the raw data - every function in the vector in effect works on that data, so how is a non-member non-friend operator== really helping?  Surely it is just spreading the vector methods around the code base rather then containing it within one area.As I mentioned above, the second one is strange, and doesn't having a non-explicit constructor go against another of his rules (the other rule making more sense in this case?);Quote:Original post by HalenkrinSurely it is just spreading the vector methods around the code base rather then containing it within one area.That's a good thing. If what we really cared about was containing code in one area, all our applications would have exactly one class. What really matters is not rolling all the vector-related code into a big ol' ugly ball, but maintaining class invariants. And class invariants are a lot easier to maintain when you have as few member functions as possible.   