如果成员函数影响逻辑状态，而不是按位状态，那么它们应该是“const”吗？

Question

我正在编写一个包含控制硬件设备的传统C API的类。 在一个简化的例子中，我可能有类似的东西：

class device
{
public:
    void set_request(int data) { legacy_set_req(p_device, data); }
    int get_response() const   { return legacy_get_rsp(p_device); }
private:
    device_handle_t *const p_device;
};

这个类本身没有按位状态; 因此，我可以选择将set_request()声明为const ，编译器会对此感到满意。 但是，从语义的角度来看，这是否是正确的方法，因为它会影响对象的可观察行为？ （即，包封的硬件设备非常确实有状态）。

Answer 1

我相信const应该反映逻辑常数，而不管内部表示。 仅仅因为你的对象只包含指向变化的东西的指针，并不意味着所有的成员函数都应该是const 。

C ++甚至具有内部表示的mutable概念，即使概念上对象没有，也需要改变。 const关键字显然不是为了表示“按位”常量。

Answer 2

如果它改变了状态，一般不应该是const 。 有问题的状态是远程拥有的（即，在受控设备中）并不会改变这一点。

Answer 3

一个有用的测试是：

基本上， const访问意味着你实际上是一个观察者。 在这里，如果一些假设的观察者在时间T2用不同的参数调用set_request() ，那么看起来好像在时间T1处调用set_request(...)然后在时间T3处调用get_response()代码将被严重搞砸。 出于这个原因， set_request(...)不应该是观察员访问-它应该是不const 。

（有警告的测试-例如，如果一个const “观察者”需要锁可明显影响非const从时序的角度另一个线程的使用，但不应该从功能一个这样做-但它是很明显如何进入你的分析的因素）。

Answer 4

与其他类型和成员资格（例如，公共，私有，虚拟）一样，const表达支持该意图的意图和语言语义（即安全特征）。 在这种情况下，即使潜在的语义是安全的，意图也会显得违反直觉。 我不会这样做。