Why does non-const method hide const overload?

Question

Given the code below:

class A
{
public:
    A(): value( 0 ) {}

    int* get()
    {
        return &value;
    }

    const int& get() const
    {
        return value;
    }

private:
    int value;
};

int main()
{
    A a;
    const int& ref_value = a.get();
}

results in the following compilation error:

prog.cpp: In function 'int main()':
prog.cpp:23:35: error: invalid conversion from 'int*' to 'int'
      const int& ref_value = a.get();
                                   ^

It seems that the overloaded get() method with const modifier does get ignored completely and the compiler sees only the non-const definition of it. It is somehow understandable since the a object is not constant. One solution would be to make the a object constant. Though there are other two solutions that makes the code compileable:

1. Change the signature of the const get() method by different name or other parameters added.

   int* get();
   const int& get_changed() const; <-- this gets called
   

2. Change the non-const get() method to return a reference instead pointer.

   int& get(); <-- this gets called
   const int& get() const; 
   

though with

int* get();
const int& get() const;

we have a compiler error.

What puzzles me is the reason behind all of these behavior.

Answer 1

When you have both a const and non-const overload of the same function with the same parameters, which one gets called depends only on the constness of the object on which you're invoking the function. So invoking on a non-const a must call the non-const overload.

It's exactly the same situation as this:

void foo(int *p);

void foo(const int *p);


int main()
{
  int i;
  const int ci;
  foo(&i);  // Calls the first overload
  foo(&ci);  // Calls the second overload
}

A const-qualified function can be called on a non-const-qualified object, but that requires a "nonconst to const" conversion. If there's an overload which doesn't require such a conversion (is a better match), it will be preferred.

Answer 2

The reason is that the compiler can't do overload resolution based on a different return type.

Only the function signature is taken into account for overload resolution. And the function signature consists only of the function name, the parameters, and the cv qualifiers - not the return type.