在 C++ 中，我希望我的接口 .h 表示 int GetSomeInt() const;.... 但实际上方法 *确实* 更新“this”。

Question

我向 const 方法添加了一些惰性初始化逻辑，这使得该方法实际上不是 const。 有没有办法让我不必从公共接口中删除“const”就可以做到这一点？

int MyClass::GetSomeInt() const
{
    // lazy logic
    if (m_bFirstTime)
    {
        m_bFirstTime = false;
        Do something once
    }

    return some int...

}

编辑：“mutable”关键字在这里起作用吗？

Answer 1

使 m_bFirstTime 可变：

class MyClass
{
  : :
  mutable bool m_bFirstTime;
};

...但这也常常表明存在设计缺陷。 所以要小心。

Answer 2

实际上，你说你不想改变头文件。 因此，您唯一的选择是放弃 this 指针的常量性...

int MyClass::GetSomeInt() const
{
    MyClass* that = const_cast<MyClass*>(this);

    // lazy logic
    if (that->m_bFirstTime)
    {
        that->m_bFirstTime = false;
        Do something once
    }

    return some int...

}

如果使用可变会引发危险信号，则会在轨道中启动危险信号存储。 做这样的事情通常是一个非常糟糕的主意。

Answer 3

我认为这个问题涉及两个概念：（1）“逻辑常量”和（2）“按位常量”。 我的意思是，从类中获取一些 int，逻辑上不会改变类，并且在大多数情况下，它不会改变位班级成员。 然而，在某些情况下，比如你的情况，确实如此。

在这些情况下，如果该方法是逻辑 const 但不是按位 const，则编译器无法知道这一点。 这就是 mutable 关键字存在的原因。 按照 John Dibling 的演示使用它，但这不是设计缺陷。 相反，在很多情况下这是必要的。 在你的例子中，我认为 int 的计算是昂贵的，所以如果不需要的话我们不想计算它。 在其他情况下，您可能希望缓存方法的结果以供以后使用等。

顺便说一句，即使您已经接受“可变”答案是正确的，您也必须更新 .h！

Answer 4

将 m_bFirstTime 成员设置为可变

Answer 5

作为 John Dibling 说，将更改的字段标记为可变。 重要的部分是 ypnos 的评论：“不要真正改变对象的状态”（正如外界所认为的那样）。 也就是说，const 方法调用之前和之后的任何方法调用都必须产生相同的结果。 否则你的设计就有缺陷。

一些有意义的事情是可变的：

• 互斥锁或其他锁类型
• 缓存的结果（不会改变）

互斥锁不是对象状态的一部分，它们只是保证数据完整性的阻塞机制。 从类中检索值的方法确实需要更改互斥体，但在执行 const 方法后，类数据和状态将与之前完全相同。

对于缓存，您必须考虑仅对检索成本高昂且假定不会更改的数据有意义（例如 DNS 结果）。 否则，您可能会将过时的数据返回给您的用户。

在 const 方法中不应更改的一些内容：

• 任何修改 const 状态的内容
  对象
• 任何影响这个或其他的东西
  方法结果

执行 const 方法的类的任何用户都将假定您的类（从外界看来）在执行期间不会发生变化。 如果不一样，就会产生很大的误导并且容易出错。 举个例子，假设 dump() 方法更改了一些内部变量（状态、值），并且在调试期间，类的用户决定在给定点转储（）对象：您的类在使用跟踪时的行为与不使用跟踪时的行为不同：完美的调试噩梦。

请注意，如果您执行惰性优化，则必须执行它们才能访问不可变数据。 也就是说，如果您的界面规定在构造过程中您将从数据库中检索一个元素，稍后可以通过常量方法访问该元素，那么如果您延迟获取数据，您最终可能会遇到用户构造对象的情况为了保留旧数据的副本，修改数据库，然后决定将以前的数据恢复到数据库中。 如果您执行了延迟获取，您最终将丢失原始值。 一个相反的例子是配置文件解析，如果在程序执行期间不允许修改配置文件。 您可以避免在需要的地方解析文件，因为知道在开始或稍后执行读取将产生相同的结果。

Answer 6

无论如何 - 请注意这将不再是线程安全的。 如果对象仅具有 const 方法（或者在初始化后仅使用 const 方法），则通常可以依赖该对象是线程安全的。 但如果这些 const 方法只是逻辑上的 const，那么你就会失去这个好处（当然除非你开始一直锁定它）。

唯一可能导致 havok 的编译器优化是编译器发现您使用相同的参数调用该方法两次，并且只重用第一个返回值 - 只要该函数在逻辑上确实是 const 就可以了，并为给定的一组参数（和对象状态）返回相同的值。 如果任何人（包括另一个线程）都可以访问该对象并对其调用非常量方法，那么即使该优化也是无效的。

专门针对这种情况将 mutable 添加到语言中。 C++ 是一种务实的语言，并且很乐意在需要时允许这样的极端情况存在。