Краткий ответ

Константная функция-член обещает не изменять состояние объекта через неявный параметр this, поэтому её безопасно вызывать и для константных, и для неконстантных объектов. Неконстантная функция может изменить объект, поэтому вызов через константный объект запрещён компилятором.

Квалификатор const относится к функции-члену и фактически ограничивает операции, доступные через this. Это правило обеспечивает проверяемую на этапе компиляции защиту от изменения объекта.

Исторический контекст

Квалификация функций-членов через const появилась как часть общей модели константности C++, чтобы интерфейс типа мог явно разделять операции чтения и изменения. Это решает практическую проблему передачи объектов через константные ссылки: вызывающий код должен иметь возможность безопасно использовать методы, не изменяющие объект.

Такой подход позволяет библиотекам принимать большие объекты по константной ссылке без копирования и при этом сохранять гарантию, что доступные через этот интерфейс операции не изменят их состояние.

Постановка проблемы

Представим тип, у которого есть методы чтения и изменения. Если константный объект мог бы вызывать метод изменения, обещание const у самого объекта не имело бы смысла: функция получила бы возможность менять данные, объявленные неизменяемыми.

Обратная ситуация безопасна. Неконстантный объект обладает как минимум теми же возможностями чтения, что и константный, поэтому вызов метода, который гарантирует отсутствие изменений, не создаёт риска.

Подробное решение

Для функции-члена без const неявный this указывает на неконстантный объект. Для const-функции this рассматривается как указатель на константный объект, поэтому внутри неё нельзя изменять обычные поля и вызывать неконстантные функции-члены того же объекта.

class Counter {
    int value_ = 0;
public:
    int value() const { return value_; }
    void increment() { ++value_; }
};

void inspect(const Counter& c) {
    c.value();
    // c.increment(); // ошибка: объект константный
}

void update(Counter& c) {
    c.value();
    c.increment();
}

Вызов value для неконстантного объекта допустим: объект можно рассматривать как константный в контексте конкретного вызова. Вызов increment для константного объекта запрещён, потому что он требует неконстантный доступ.

Класс может иметь две перегрузки одного метода, различающиеся квалификатором const. Для неконстантного объекта обычно выбирается неконстантная версия, а для константного — только const-версия. Это позволяет, например, возвращать изменяемую ссылку в одном случае и константную ссылку в другом.

const не гарантирует полной неизменности всего, что логически связано с объектом. Поле, объявленное как mutable, можно изменять внутри const-функции; обычно его используют для кэша, счётчика обращений или другой технической детали, не являющейся логическим состоянием объекта. Кроме того, const не защищает объекты, на которые указывают указатели или ссылки внутри класса.

Компромисс заключается в выборе модели константности. Слишком слабая квалификация методов ухудшает безопасность интерфейса, а чрезмерное использование mutable может скрыть реальные изменения состояния и усложнить многопоточное использование.

Ситуация из практики

В контейнере хранился кэш вычисленных характеристик объекта. Метод чтения был объявлен неконстантным только потому, что при первом обращении обновлял внутреннее кэш-поле. Из-за этого контейнер нельзя было корректно использовать через константную ссылку: компилятор запрещал вызов метода.

Рассматривались два варианта. Сделать весь метод неконстантным было проще, но это ухудшало интерфейс и мешало работе с константными объектами. Убрать кэш сохраняло строгую семантику, но приводило к повторным дорогим вычислениям.

Выбрали const-метод с отдельным mutable-полем кэша, поскольку изменение кэша не меняло логическое значение объекта. Доступ к кэшу дополнительно синхронизировали, так как mutable не делает операцию потокобезопасной. В результате метод стал доступен через константные ссылки, а повторные вычисления исчезли.

Что кандидаты часто упускают

Дополнительный вопрос: можно ли вызвать константную функцию-член через указатель или ссылку на неконстантный объект?

Да. Неконстантный объект допускает константный доступ, поэтому ссылка или указатель могут использоваться для вызова const-метода. При этом сам объект не становится константным навсегда: ограничение действует только в рамках данного выражения и конкретного пути доступа.
Дополнительный вопрос: что произойдёт, если у класса есть две версии метода, одна с const, другая без него?

Для неконстантного объекта предпочтительной является неконстантная перегрузка, поскольку она сохраняет более широкий доступ к объекту. Для константного объекта неконстантная версия недоступна, поэтому выбирается const-перегрузка.

Это часто применяют для методов доступа к полям: неконстантный объект может получить изменяемую ссылку, а константный — только константную. Возврат изменяемой ссылки из const-метода нарушил бы гарантию константности.
Дополнительный вопрос: означает ли const у функции-члена, что она не может изменить вообще никакие данные?

Нет. Она не может изменять обычные подобъекты через this, но может изменять mutable-поля. Также она может менять внешнее состояние, например объект, доступный через указатель, глобальное состояние или вызываемую функцию с побочными эффектами.

Поэтому const выражает ограничение на изменение наблюдаемого объекта через данный интерфейс, а не универсальную гарантию отсутствия любых побочных эффектов. При проектировании API важно сохранять это ограничение честным с точки зрения логической модели типа.