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

Dani AI

Generated

Short answer: keep the non-member operator<< taking a const reference and make any accessors you call from it const. The compiler error means the object you have is being treated as const, so only const-qualified member functions can be invoked. Returning a top-level const for simple value types (like const double) is unnecessary and can cause more trouble than it solves.

Checklist to troubleshoot the exact error:

  1. Make the accessor a const method (so it can be called on const objects).
  2. Verify the method is declared const in the class and defined const in the .cpp (a common mismatch).
  3. Keep operator<< as T const& so it accepts temporaries and const objects.
  4. Don’t return primitive/value types as const — it adds no safety and can hinder moves/assignment for class types.
  5. If you must update cached state inside a logically-const method, use mutable for the cache member — sparingly.
  6. Avoid const_cast except as a last resort; prefer fixing the const-correctness of the API.

A few practical notes tied to the thread: ’s advice is exactly right — mark methods that do not change observable state as const so they’re usable on const references. ’s Normal() example should be a const method if it doesn’t alter the Plane. To : const is a contract and compiler-enforced guard; it prevents accidental mutation and documents intent.

If you still see errors, read the compiler message — it usually tells you which function is missing the const qualifier. Fix the declaration/definition mismatch first; after that most const-related issues go away.

Recommended Answers

All 5 Replies

> 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.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.