Является ли неправильной практикой для оператора == мутировать свои операнды?

Ответ 1

Похоже, что это действительно действующая утилита для члена mutable. Вы можете (и должны) по-прежнему сделать operator== значение параметра по ссылке const и дать классу a mutable член для хеш-значения.

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

Ответ 2

Используйте mutable для данных, которые вы хотите кэшировать, но которые не влияют на общий интерфейс.

U теперь, "mutate" → mutable.

Затем подумайте с точки зрения логического const -ness, что гарантирует, что объект предлагает код использования.

Ответ 3

Вы не должны изменять объект при сравнении. Однако эта функция не логически модифицирует объект. Простое решение: make hash mutable, поскольку вычисление хэша является формой обналичивания. Видеть: Имеет ли ключевое слово "изменчивое" какие-либо цели, кроме возможности изменения переменной с помощью функции const?

Ответ 4

• Не рекомендуется побочный эффект в функции сравнения или оператора. Будет лучше, если вы сможете вычислить хэш как часть инициализации класса. Другой вариант заключается в том, что за это отвечает класс менеджера. Обратите внимание: что даже то, что кажется невинной мутацией, потребует блокировки в многопоточном приложении.
• Также я рекомендую избегать использования оператора равенства для классов, где структура данных не является абсолютно тривиальной. Очень часто прогресс проекта создает необходимость в сравнительной политике (аргументах), а интерфейс оператора равенства становится недостаточным. В этом случае добавление метода сравнения или функтора не обязательно должно отражать стандартный интерфейс operator == для неизменности аргументов.
• Если 1. и 2. кажутся излишними для вашего случая, вы можете использовать ключевое слово С++, изменяемое для члена хеш-значения. Это позволит вам изменить его даже из метода const класса или объявленной переменной const

Ответ 5

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

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

Ответ 6

Вы можете перейти на изменяемый маршрут, но я не уверен, что это необходимо. Вы можете сделать локальный кеш при необходимости, не используя mutable. Например:

#include <iostream>
#include <functional> //for hash

using namespace std;

template<typename ReturnType>
class HashCompare{
public:
    ReturnType getHash()const{
        static bool isHashed = false;
        static ReturnType cachedHashValue = ReturnType();
        if(!isHashed){
            isHashed = true;
            cachedHashValue = calculate();
        }
        return cachedHashValue;
    }
protected:
    //derived class should implement this but use this.getHash()
    virtual ReturnType calculate()const = 0;
};



class ReadOnlyString: public HashCompare<size_t>{
private:
    const std::string& s;
public:
    ReadOnlyString(const char * s):s(s){};
    ReadOnlyString(const std::string& s): s(s){}

    bool equals(const ReadOnlyString& str)const{
        return getHash() == str.getHash();
    }
protected:
    size_t calculate()const{
        std::cout << "in hash calculate " << endl;
        std::hash<std::string> str_hash;
        return str_hash(this->s);
    }
};

bool operator==(const ReadOnlyString& lhs, const ReadOnlyString& rhs){ return lhs.equals(rhs); }


int main(){
    ReadOnlyString str = "test";
    ReadOnlyString str2 = "TEST";
    cout << (str == str2) << endl;
    cout << (str == str2) << endl;
}

Вывод:

 in hash calculate 
 1
 1

Можете ли вы дать мне вескую причину, чтобы сохранить, почему сохранение isHashed в качестве переменной-члена необходимо вместо того, чтобы сделать его локальным, где это необходимо? Обратите внимание, что мы можем еще больше уйти от "статического" использования, если мы действительно хотим, все, что у нас есть, - это сделать выделенную структуру/класс