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访问设备实例的代码会干扰非const访问的代码操作

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

（测试有一些警告 - 例如，如果一个const“观察者”需要一个锁定，它显然会从时间角度影响另一个线程的非const使用，但不应这样做从功能性的 - 但很明显如何将其纳入你的分析中。）

Answer 4

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

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

4 个答案: