C 包装器的成员函数的 c++ const-ness答案

【问题标题】：c++ const-ness of member functions for a C wrapperC 包装器的成员函数的 c++ const-ness
【发布时间】：2012-07-04 22:35:29
【问题描述】：

我有一个对象，在最基本的层面上，它看起来像这样：

#include <X11/Xlib.h>

class x_link {
    public:
        x_link()
        {
            display_ = XOpenDisplay(NULL);
        }

        ~x_link()
        {
            XCloseDisplay(display_);
        }

        Display* display_ptr() const
        {
            return display_;
        }

    private:
        Display* display_;
};

我想知道在这种情况下“const”x_link::display_ptr() 应该如何。

这个较老的问题Should member functions be “const” if they affect logical state, but not bitwise state? 给我的印象是，由于我的方法（本身）不会影响对象的逻辑或按位状态，所以const 是要走的路。

但同时，提供Display* 允许用户破坏对象（例如，通过自己调用XCloseDisplay()），这将是非常非常规的事情。

有什么想法吗？

【问题讨论】：

为什么要提供对私有指针的访问权限？
因为生命短暂而 Xlib 巨大。除非我在这个对象中为我关心的 Xlib 的所有部分提供一个接口（这是可能的，但这意味着一个大的、专门的对象），否则其他代码将需要访问该指针。
这看起来像一个简单的 RAII 样式使用。您为什么不将std::shared_ptr（或boost::shared_ptr）与自定义删除器一起使用？它将帮助您使复制构造函数和赋值之类的东西正常工作。
在同一个指针上调用 XCloseDispaly 两次是否安全？我问是因为您在这里违反了三规则，并且您可能会在某些时候遇到双重删除。
@Ed S.：不是。在实际对象中，我禁用了复制构造函数和赋值运算符，因为在这种情况下（对我而言）这种用法并没有真正“意义”。如果有什么变化，我会重新审视它。

标签： c++ class constants

【解决方案1】：

这个类看起来像一个简单的包装类，其目的主要是包装一个 C 接口。在这种情况下，我建议您根本不要使用 const 使程序复杂化。

我保留将 const 用于对象或函数是只读的明确情况。

Const 是众多 C++ 特性之一，它经常欺骗程序员使他们的程序变得不必要地复杂。

【讨论】：

感谢您的提示；我必须记住这一点。 const 确实已经给我造成了足够多的麻烦。
当类本身将用作 const 实例时，实际上只需要将函数设为 const：“const x_link xl;”或“const x_link *xl”。但是拥有该类的 const 实例的唯一原因是，它是否要在一个上下文中使用，其中说它的状态不能改变是有意义的。思考用法可以帮助人们避免复杂的哲学问题，例如什么是改变复杂对象的状态。