operator== 改变其操作数是不好的做法吗？

Question

场景

我有一个班级，我希望能够比较其是否相等。该类很大（它包含一个位图图像），我将对其进行多次比较，因此为了提高效率，我对数据进行哈希处理，并且仅在哈希匹配时进行完全相等检查。此外，我只会比较我的对象的一小部分，所以我只在第一次完成相等性检查时计算哈希值，然后将存储的值用于后续调用。

示例

class Foo
{
public:

   Foo(int data) : fooData(data), notHashed(true) {}

private:

   void calculateHash()
   {
      hash = 0; // Replace with hashing algorithm
      notHashed = false;
   }

   int getHash()
   {
      if (notHashed) calculateHash();
      return hash;
   }

   inline friend bool operator==(Foo& lhs, Foo& rhs)
   {
      if (lhs.getHash() == rhs.getHash())
      {
         return (lhs.fooData == rhs.fooData);
      }
      else return false;
   }

   int fooData;
   int hash;
   bool notHashed;
};

背景

根据this answer上的指导，等式运算符的规范形式是：

inline bool operator==(const X& lhs, const X& rhs);

此外，以下关于运算符重载的一般建议is given：

始终坚持运营商众所周知的语义。

问题

1. 我的函数必须能够改变它的操作数才能执行散列，所以我不得不将它们设为非const。这是否有任何潜在的负面影响（示例可能是标准库函数或 STL 容器，它们期望 operator== 具有 const 操作数）？

2. 如果突变没有任何可观察到的影响（因为用户无法看到哈希的内容），是否应该将突变的operator== 函数视为与其众所周知的语义相反？

3. 如果以上任何一个的答案都是“是”，那么更合适的方法是什么？

Answer 1

您可以走可变路线，但我不确定是否需要这样做。您可以在需要时进行本地缓存，而无需使用 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 作为成员变量而不是将其本地化到需要的地方？请注意，如果我们真的想要，我们可以进一步摆脱“静态”使用，我们要做的就是创建一个专用的结构/类

Answer 2

是的，引入语义上意想不到的副作用总是一个坏主意。除了提到的其他原因：始终假设您编写的任何代码将永远只被甚至没有听说过您的名字的其他人使用，然后从这个角度考虑您的设计选择。

当使用您的代码库的人发现他的应用程序很慢并尝试对其进行优化时，如果它在 == 重载中，他会浪费很多时间来寻找性能泄漏，因为他没有预料到，从从语义上看，要做的不仅仅是简单的对象比较。在语义便宜的操作中隐藏潜在的昂贵操作是一种不好的代码混淆形式。

Answer 3

1. 不建议在比较函数或运算符中有副作用。如果您可以设法在类的初始化过程中计算哈希值，那就更好了。另一种选择是有一个负责的管理器类。注意：即使是看似无害的突变也需要锁定多线程应用程序。
2. 此外，我建议避免对数据结构并非绝对微不足道的类使用相等运算符。很多时候，项目的进展会产生对比较策略（参数）的需求，而相等运算符的接口变得不够充分。在这种情况下，添加 compare 方法或仿函数不需要反映标准 operator== 接口以实现参数的不变性。
3. 如果 1. 和 2. 在您的情况下显得过于矫枉过正，您可以将 c++ 关键字 mutable 用于哈希值成员。这将允许您甚至从 const 类方法或 const 声明的变量修改它

Answer 4

您不应该在比较时修改对象。但是，此函数不会在逻辑上修改对象。简单的解决方案：使hash 可变，因为计算哈希是一种兑现形式。看： Does the 'mutable' keyword have any purpose other than allowing the variable to be modified by a const function?

Answer 5

对于mutable 成员来说，这似乎是一个完全有效的用例。您可以（并且应该）仍然让您的 operator== 通过 const 引用获取参数，并为该类提供一个 mutable 成员作为哈希值。

然后你的类将有一个哈希值的 getter，它本身被标记为 const 方法，并且在第一次调用时惰性计算哈希值。这实际上是为什么 mutable 被添加到语言中的一个很好的例子，因为它不会从用户的角度改变对象，它只是一个用于在内部缓存昂贵操作的值的实现细节。

Answer 6

将mutable 用于您要缓存但不影响公共接口的数据。

你现在，“变异”→mutable。

然后考虑逻辑const-ness，什么保证对象提供给使用代码。