4

i have an object that, at its most basic level, looks like this:

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

i was wondering how "const" x_link::display_ptr() should be in a case like this.

this older question, Should member functions be “const” if they affect logical state, but not bitwise state?, gives me the impression that since my method doesn't (itself) impact either the logical or bitwise state of the object, const is the way to go.

but at the same time, providing the Display* allows users to break the object (for example, by calling XCloseDisplay() themselves), which would be a very non-const thing to do.

any thoughts?

Community
  • 1
  • 1
tecu
  • 540
  • 2
  • 7
  • 1
    Why do you provide access to the private pointer? – Jesse Good Jul 04 '12 at 22:45
  • because life is short and Xlib is huge. unless i provide an interface to all the parts of Xlib i care about within this object (which is possible, but it means a big, specialized object), other code will need access to that pointer. – tecu Jul 04 '12 at 23:20
  • This looks like a simple RAII style use. Any reason why you dont use `std::shared_ptr` (or `boost::shared_ptr`) with a custom deleter? It will help you get things like copy constructors and assignment working right. – Michael Anderson Jul 05 '12 at 00:28
  • Is it safe to call XCloseDispaly on the same pointer twice? I ask because you have broken the rule of three here and you're likely to run into a double delete at some point. – Ed S. Jul 05 '12 at 01:17
  • @Ed S.: it is not. in the actual object, i have disabled the copy constructor and the assignment operator because that usage doesn't really 'make sense' in this context (to me). i will revisit it if something changes. – tecu Jul 05 '12 at 01:55
  • @Michael Anderson: i didn't know you could use custom deleters with those types. i guess that's another thing i'll have to look into. (thanks!) – tecu Jul 05 '12 at 01:58
  • @tecu: That's fine then; I only mentioned it because I don't see them made private in your example. – Ed S. Jul 05 '12 at 02:04

1 Answers1

1

This class looks like a simple wrapper class whose purpose is primarily to wrap a C interface. In that case I advise you to not complicate your program by using const at all.

I reserve the use of const for clear cut cases where an object or function is read-only.

Const is one of the many C++ features that often trick programmers into making their programs unnecessarily complicated.

Matt Kimberling
  • 93
  • 5
  • thank you for the tip; i'll have to keep that in mind. const has certainly caused me enough hangups already. – tecu Jul 05 '12 at 00:00
  • 1
    One really only needs to make functions const when the class itself is going to be used as a const instance: "const x_link xl;" or "const x_link *xl". But the only reason to have a const instance of the class is if it is going to be used in a context where its meaningful to say its state cannot be changed. Thinking about the usage can help one avoid complicated philisophic questions like what constitutes changing the state of a complicated object. – Matt Kimberling Jul 05 '12 at 00:24