I posted a while back about how to overload <<

It seems all the examples online have the second argument as const, ie

ostream & operator << (ostream &output, const Point &p);

but if I have a member function that simply returns a double

double Point::getX()
{
return x_;
}

In the << function it complains about the const

error: the object has cv-qualifiers that are not compatible with the member function
            object type is: const Point

So I've fixed it two ways:
1) make the getX() function return a const double
2) change the << function to not accept a const, ie

ostream & operator << (ostream &output, const Point &p);

So should accessor functions always return const? Or is it ok to remove const from the << definition?

Thanks!

Dave

> So should accessor functions always return const?
Accessors should be const methods at the very least, because the object state isn't changed in the body:

double Point::getX() const
{
  return x_;
}

That should clear up the error without forcing you to make the return value const. Edward tries to make every method that doesn't affect the object state a const method.

> Or is it ok to remove const from the << definition?
Ed's const rule applies to parameters too. If the parameter can be const, it should be const, so the overloaded operator<< is:

ostream & operator << (ostream &output, const Point &p);

Because the Point object should be treated as read-only for that operator.

ok, i'll start making that a habbit

here's another question though:

Vector3 Plane::Normal()
{
        double norm = sqrt(pow(A,2) + pow(B,2) + pow(C,2));
	geom_Vector3 V(A/norm, B/norm, C/norm);
	return V;
}

then in the << function, I can't do

... << P.Normal();

because Normal() isn't a const function. However, I should be able to do

geom_Vector3 N = P.Normal();
  output << "Plane Normal: " << N << endl;

but it's telling me

error: the object has cv-qualifiers that are not compatible with the member function
            object type is: const Plane
    Vector3 N = P.Normal();

Why can't I do that??

> because Normal() isn't a const function
Why not? Edward doesn't see any obvious changes to the object state, so it can be a const method. If you get to the point where you need a const method but the state has to change, consider making the state mutable:

class Test {
  mutable int _state;
public:
  void ChangeState(int newState) const {
    _state = newState;
  }
};

int main()
{
  const Test t;

  t.ChangeState(10);
}

It's pretty rare that you'd need to do that though.

> Why can't I do that??
Because you're using a const object in the context of a non-const object. If the object is const, you can't even call a non-const method with it.

Ok, I came across this post because of an error I had that was because of a const that was introduced through netbeans automatically generating a getter function for me. When I removed all the const 's from my code, I was fine again. However, Radical Edward seems to be an expert and suggests as was automated for me that const is something that should be used. Does anyone have a reason for using a const? Does anyone have an explanation for what a const is? All I've ever seen about const is that they get in the way of compilations, adding headaches of const_cast 'ing and stuff. Is there a benefit to const 's? And what is this _state thing?

Const just means that the function is unable to modify the value. Of course if you don't want to change the value, then just don't change it! Const just provides a double check in case you made a mistake.

This article has been dead for over six months. Start a new discussion instead.