C++ RAII to manage change and reversion of object state

Question

I have a class foo. Operations on foo require a call to foo::open(), a number of foo::write(), and must end with a foo::close() call:

#include <iostream>

class foo
{
public:
    foo()
    {
        std::cout << "foo::foo()" << std::endl;
    }
    ~foo()
    {
        std::cout << "foo::~foo()" << std::endl;
    }    
    void open()
    {
        std::cout << "foo::open()" << std::endl;
    }
    void close()
    {
        std::cout << "foo::close()" << std::endl;
    }
    void write(const std::string& s)
    {
        std::cout << "foo::write(" << s << ")" << std::endl;
    }    
private:    
    // state that must be retained for entire lifetime of object
};

static void useFoo(foo& my_foo)
{
    my_foo.open();
    my_foo.write("string1");
    my_foo.write("string2");
    my_foo.close();
}

int main(  int argc, char* argv[] )
{
    foo my_foo;
    useFoo(my_foo);
    useFoo(my_foo);
}

As expected, this outputs the following:

foo::foo()
foo::open()
foo::write(string1)
foo::write(string2)
foo::close()
foo::open()
foo::write(string1)
foo::write(string2)
foo::close()
foo::~foo()

I want to give users of my class foo a way of ensuring that they don't forget to call foo::close(), and to ensure that foo::close() gets called if an exception happens. I can't use foo's destructor as foo must continue to exist after a foo::close(), ready for the next foo::open().

I came up with this RAII implementation:

#include <iostream>

class foo
{
public:
    class opener
    {
    public:
        explicit opener(foo& my_foo):foo_(my_foo)
        {
            foo_.open();
        };
        ~opener()
        {
            foo_.close();
        };    
    private:
        foo& foo_;
    };    
    foo()
    {
        std::cout << "foo::foo()" << std::endl;
    }
    ~foo()
    {
        std::cout << "foo::~foo()" << std::endl;
    }    
    void open()
    {
        std::cout << "foo::open()" << std::endl;
    }
    void close()
    {
        std::cout << "foo::close()" << std::endl;
    }
    void write(const std::string& s)
    {
        std::cout << "foo::write(" << s << ")" << std::endl;
    } 
    opener get_opener()
    {
        return(opener(*this));
    }   
private:
    // state that must be retained for entire lifetime of object    
};


static void useFoo(foo& my_foo)
{
    foo::opener my_foo_opener = my_foo.get_opener();
    my_foo.write("string1");
    my_foo.write("string2");
}

int main(  int argc, char* argv[] )
{
    foo my_foo;
    useFoo(my_foo);
    useFoo(my_foo);
}

For simplicity I haven't included the obvious improvement of having the foo::opener class expose the foo::write() method, though in a real object I'd do this to prevent a write() being possible before an open().

EDIT As Nawaz points out below, a real class would also need a copy constructor and assignment operator.

This seems quite a lot of boilerplate just to ensure that a close() gets called. Two questions arise:

1. Is this still simpler than forcing the users of my class to use a try/catch?

2. Is there a simpler way to achieve what I want: provide the basic exception guarantee and ensure that close() always follows open()?

Answer 1

The nested class opener should implement the copy-semantics, as the default code generated by the compiler would produce undesirable result, if I correctly understood your intention.

So please implement copy-constructor, and copy-assignment.

Or alternatively, you may want to disable copy-semantic altogether, by making their declarations¹ private, much like implementation of all standard stream classes. I would prefer this approach.

^{1. Note that you don't need to define them. Just declaring them in the private section is enough.}

Answer 2

Can close ever fail? If it can, then you're going to need to take extra care regardless of approach. I think the RAII way is simpler than forcing exception handling/closing on your users though.

Is foo really so complex (or is it a global?) to create and destroy that you can't just have its destructor call close instead of using the opener to do the matching open/close?

Or if this is implementing some sort of transaction semantics I can't see a simpler way than the opener class (but as noted in other answers you probably want to disable copying and assignment of the opener class).

Answer 3

I think you should separate your concerns:

• one class to store the state that is carried throughout
• one class to handle the transient state within a open/close, which also takes care of all the "transient" operations like write

The "transient" class takes the "data" class as parameter (by reference) and will update it during the various method calls.

Then you can use typical RAII on the transient class and still have state propagated throughout.

Answer 4

This is a classic case for using RAII. Do use the constructor and destructor: if you want to open() again, instantiate a new foo. The idea of RAII is that an instantiation represents a single resource use. That's how you get the guarantee for resource cleanup.

struct foo {
    foo() { open(); }
    ~foo() { close(); }
    void write(const std::string& s);
private:  // or public
    foo(const foo&);
    foo& operator=(const foo&);
};

// ...
{ foo fooa;
    fooa.write("hello 0");
} { foo foob;
    foob.write("hello 1");
}

Answer 5

You could add a flag to the class, that is set to true if you called open() and to false if you called close(). If open() is called you can check if the flag is true or false and and close if you need to do so before proceeding.