2012-07-04 32 views
4

我有一个对象,在其最基本的级别,看起来像这样:C++常量性为C包装

#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_; 
}; 

我想知道“常量”如何x_link::display_ptr()应该在的情况下喜欢这个。

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

但与此同时,提供Display*允许用户打破对象(例如,通过自己调用XCloseDisplay()),这将是一个非常非常量的事情。

有什么想法?

+1

为什么你提供访问私人指针? –

+0

,因为生命短暂,Xlib巨大。除非我在这个对象中提供了一个我关心的Xlib的所有部分的接口(这是可能的,但它意味着一个大的专用对象),其他代码将需要访问该指针。 – tecu

+0

这看起来像一个简单的RAII风格的使用。任何你为什么不用'std :: shared_ptr'(或'boost :: shared_ptr')来定制删除器的原因?它将帮助你获得像复制构造函数和赋值工作的东西。 –

回答

1

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

我保留使用const来清除对象或函数为只读的情况。

Const是许多C++特性之一,它常常欺骗程序员使其程序变得不必要的复杂。

+0

谢谢你的提示;我必须记住这一点。 const已经给我足够的hangups了。 – tecu

+1

当类本身将被用作一个常量实例时,一个实际上只需要使函数为常量:“const x_link xl;”或“const x_link * xl”。但是拥有该类的const实例的唯一理由是它是否将用于其有意义的状态无法更改的上下文中。考虑使用可以帮助避免复杂的哲学问题,例如什么构成改变复杂对象的状态。 –