Here is my example
Code:
```#include <iostream>
#include <vector>
using namespace std;

class Point3d {
public:
/**
* Constructor with given value that will be set to all coordinates.
* @param v - the value
*/
Point3d( double v )
: _x( v ), _y( v ), _z( v ) {};

/**
* Returns the first coordinate of this point (constant).
* @return the \b first coordinate
*/
const double x() const { return _x; };

/**
* Returns the second coordinate of this point (constant).
* @return the \b second coordinate
*/
const double y() const { return _y; };

/**
* Returns the third coordinate of this point (constant).
* @return the \b third coordinate
*/
const double z() const { return _z; };

/**
* Multiply all coordinates of this point with the given value.
* @param w - the multiplier
*/
void operator *= ( const double w ) {
_x *= w; _y *= w; _z *= w;
};

bool operator >= ( const Point3d& p ) {
return ( _x >= p.x()  && _y => p.y() && _z => p.z() );
};
private:
double _x;
double _y;
double _z;
};

int main()
{
Point3d q(2);
Point3d w(1);
if(q>=w) cout<<"OK\n";
return 0;
}```
Why I get this error and how I fix it? I want to understand why this happens.
Code:
```main.cpp: In member function `bool Point3d::operator>=(const Point3d&)':
main.cpp:44: error: expected primary-expression before '>' token
main.cpp:44: error: expected primary-expression before '>' token```
I thought, going on like with the other operator I overloaded, *=, would work just fine...

2. "=>" means what in C++ ?

Edit: typo of ">=" or does it really exist in C++?

Tim S.

3. I was watching who was one and I saw only you around from the big guys, so I was hoping for your answer.

And yes, that was it, a silly typo was made on 11/8/2013 at 4:28 in the morning!

4. There is no such operator as =>. It is <=. The order of characters matters.

1) it is usually a good idea for an operator>= to be a const function, since it shouldn't change either operand. You've made the parameter const but not the operator (which is telling the compiler that, in an expression of the form "a >= b" that your operator may change a.

2) Declaring a function argument const gives no benefit if the argument is passed by value (since a copy is passed, any change to the argument doesn't change what was passed). But that's what you have done with operator *=().

3) Since operator>=() is a member function, there is no need for it to use p.x() rather than p._x. It has access to p's privates, and doesn't really need to use accessor functions. If you insist on using accessors, your code is generally clearer and easier to understand if it is consistent - use "x() >= p.x()" or "_x >= p._x" rather than mixing the two forms.

4) Be careful with using member names prefixed by an underscore. Names beginning with underscores are reserved identifiers in some circumstances (in the global namespace) and, if you run into clashes with such things in your implementation (compiler and library), the resultant program bugs tend to be VERY difficult to track down.

5. Statha was a bit faster.

I just came across the problem with the const thing.

I like the point 3 you said and for the point 4 I agree.

Well, actually this file is been enhanced by me, so the *=() operator was not written by me. Probably he did it, in order to give a plus in readability.

Thank you both gentlemen.

6. It really doesn't make sense to compare points on a member-by-member basis. You should instead be comparing their respective absolute distance from the origin (ie: Point(0, 0, 0)); just take the square root of the sum of the squares of each member. Then you can simply define all of your comparison operators in terms of these two scalar values like so:

Code:
```friend double compare( const Point& lhs, const Point& rhs )
{
return lhs.distance( ) - rhs.distance( );
}
friend bool operator < ( const Point& lhs, const Point& rhs )
{
return compare( lhs, rhs ) < 0;
}
friend bool operator <= ( const Point& lhs, const Point& rhs )
{
return compare( lhs, rhs ) <= 0;
}
// etc...```

7. Originally Posted by Sebastiani
It really doesn't make sense to compare points on a member-by-member basis.
In real terms, it doesn't make much sense to compare points for anything other than equality and inequality.

You approach makes even less sense, IMHO, than std10093's. Consider comparing the points (1,0) and (0,1). operator>=() and operator<=() would each return true, according to your approach, while operator<() and operator>() would both return false. The only way an operator==() and operator!=() could behave consistently with that is to report (1,0) and (0,1) as equal.

There is a reason that std::complex types only support operator==() and operator!=(), but no other comparison operators. Personally, I'd do the same with a point class.

8. Originally Posted by grumpy
In real terms, it doesn't make much sense to compare points for anything other than equality and inequality.

You approach makes even less sense, IMHO, than std10093's. Consider comparing the points (1,0) and (0,1). operator>=() and operator<=() would each return true, according to your approach, while operator<() and operator>() would both return false. The only way an operator==() and operator!=() could behave consistently with that is to report (1,0) and (0,1) as equal.

There is a reason that std::complex types only support operator==() and operator!=(), but no other comparison operators. Personally, I'd do the same with a point class.
Yeah, I don't know why, but for some reason I was thinking in terms of vectors! Oh well, that's what I get for posting after biking all day in the hot sun...

9. Yeah, well.

If you were thinking in terms of std::vector's, they don't support operator>=() either.

If you were thinking in terms of vectors in (say) cartesian space, it is unusual to describe two vectors as being equal if their lengths are the same, but orientation is different.

10. Um, yeah, I think I'm just going to go to bed now...

11. Well, actually, yesterday when I went to sleep at 7 in the morning I realized my "fault", so they were already gone, before coming here.