Why I can't define compare without constant - c++

Question

If I define my compare function like this:
bool compare(Student& a, Student& b)
{
return a.n < b.n;
}
g++ will complain:
g++ -Wall main.cpp -o main
In file included from /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/algorithm:63:0,
from main.cpp:1:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h: In function ‘_RandomAccessIterator std::__unguarded_partition(_RandomAccessIterator, _RandomAccessIterator, const _Tp&, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<Student*, std::vector<Student> >, _Tp = Student, _Compare = bool (*)(Student&, Student&)]’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h:2261:78: instantiated from ‘_RandomAccessIterator std::__unguarded_partition_pivot(_RandomAccessIterator, _RandomAccessIterator, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<Student*, std::vector<Student> >, _Compare = bool (*)(Student&, Student&)]’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h:2302:62: instantiated from ‘void std::__introsort_loop(_RandomAccessIterator, _RandomAccessIterator, _Size, _Compare) [with _RandomAccessIterator = __gnu_cxx::__normal_iterator<Student*, std::vector<Student> >, _Size = long int, _Compare = bool (*)(Student&, Student&)]’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h:5250:4: instantiated from ‘void std::sort(_RAIter, _RAIter, _Compare) [with _RAIter = __gnu_cxx::__normal_iterator<Student*, std::vector<Student> >, _Compare = bool (*)(Student&, Student&)]’
main.cpp:38:51: instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h:2229:4: error: invalid initialization of reference of type ‘Student&’ from expression of type ‘const Student’
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_algo.h:2232:4: error: invalid initialization of reference of type ‘Student&’ from expression of type ‘const Student’
Compilation exited abnormally with code 1 at Mon May 28 08:05:35
But if I define the compare with const type, it will compile and works fine.
And here is all the code:
class Student {
public:
Student(string);
string n;
};
bool compare(Student& a, Student& b)
{
return a.n < b.n;
}
Student::Student(string name) { n = name; }
int main()
{
Student A = Student("A");
Student B = Student("B");
vector<Student> students;
students.push_back(B);
students.push_back(A);
sort(students.begin(), students.end(), compare);
cout << "After sort" << endl;
for(vector<Student>::iterator i = students.begin(); i != students.end(); ++i) {
cout << "Student: " << i->n << endl;
}
return 0;
}

Answer 1

In this implementation, std::sort uses
const _Tp& std::__median(const _Tp&, const _Tp&, const _Tp&, _Compare);
In your case, _Tp is student, and _Compare is compare.
So you basically have
const Student& std::__median(const Student&, const Student&, const Student&,
bool (*)(Student&, Student&) )
or similar. Obviously, the callback can't be applied to the parameters are they are converted to const, so the failure.
Make the parameters to your compare method const.

Answer 2

I don't believe there is a requirement in the standard that says the parameters to the function must be const, so I believe your implementation is in error for rejecting it. However, there is a requirement that the function not modify the arguments:
From the standard -- 25.4/2
Compare is a function object type (20.8). The return value of the
function call operation applied to an object of type Compare, when
contextually converted to bool (4), yields true if the first argument
of the call is less than the second, and false otherwise. Compare comp
is used throughout for algorithms assuming an ordering relation. It is
assumed that comp will not apply any non-constant function through the
dereferenced iterator.
And the signature of std::sort from 25.4.1.1
template<class RandomAccessIterator, class Compare>
void sort(RandomAccessIterator first, RandomAccessIterator last, Compare comp)
So since your function is not allowed to modify its arguments, it really should be taking them in as const, but the standard does not require that. So while your implementation may be in error, I believe it is a forgivable error, as it manages to call attention to the fact that either your function is in violation of the standard by modifying its arguments, or it is not const-correct.

Answer 3

You should make it const since it leaves the two parameters the same.