Is it possible to prevent an RAII-style class from being instantiated "anonymously"?

Question

Suppose I have an RAII-style C++ class:

class StateSaver
{
  public:
    StateSaver(int i) { saveState(); }
    ~StateSaver() { restoreState(); }
};

...to be used like so in my code:

void Manipulate()
{
  StateSaver save(1);

  // ...do stuff that modifies state
}

...the goal being to enter some state, do stuff, then leave that state when I leave that scope. Is there a way to make this typo not compile (or warn, or somehow complain so that the mistake can be noticed)?

void Manipulate()
{
  StateSaver(1); // ruh-roh, state saved and immediately restored!

  // ...do stuff that modifies state
}

I'm not aware of anything in C++ itself which I could use to prevent this, but that doesn't mean it doesn't exist. If there isn't anything in C++, compiler-specific extensions would be acceptable. I'm primarily interested in anything targeting gcc and msvc (someday icc, ideas for other compilers welcome but less likely to be useful) so hacks for any of them would be useful (abstracted into appropriately #ifdef'd macro definitions, of course).

Answer 1

SaveMatrix save(); doesn't define an object either. It declares a function.

There's very little you can do to prevent others (or yourself, FTM) from doing something else than they wanted to. The only thing I can think of is not writing the code itself, but writing a macro instead.

#define SAVE_MATRIX SaveMatrix save ## __LINE__

However, this is quite ugly. OTOH, it does catch the error at compile-time.

Answer 2

I'm not sure if anything can be done at compile-time. For a run-time check, you could do this:

struct SaveMatrix
{
    SaveMatrix(const SaveMatrix& that) {
        assert(this == &that);
        glPushMatrix();
    }
    ~SaveMatrix() { glPopMatrix(); }
};

Which requires the client to write:

SaveMatrix sm(sm);

and there's no way to do the same for a temporary without binding it to an identifier (at which point it's no different from an auto variable).

Answer 3

The class can never tell if it was instantiated as a temporary (SaveMatrix()) or as a variable (SaveMatrix save;). I think the best way to stop the programmer doing that without stack or macro hacks is to force a member function call after construction, eg:

class RAII
{
public:
    bool valid;
    RAII()
     : valid(false)
    {
     cout << "RAII ctor" << endl;
    }

    void Do()
    {
     valid = true;
    }

    ~RAII()
    {
     assert(valid);
     cout << "RAII dtor" << endl;
    }
};

This then works as follows:

{
 // Intended use
 RAII raii;
 raii.Do();

 cout << "Some task" << endl;
}

{
 // Woops: forgot Do()
 RAII raii;

 cout << "Some task" << endl;
}

{
 // Woops: forgot Do()
 RAII();

 cout << "Some task" << endl;
}

{
 // Programmer shot self in foot, hopefully the act of typing this would make them realise that
 RAII().Do();

 cout << "Some task" << endl;
}

Answer 4

I actually had to tweak my solution in a bunch of ways from the variant Waldo posted, but what I eventually got to is a macro-ized version of:

class GuardNotifier
{
    bool* notified;
  public:
    GuardNotifier() : notified(NULL) { }
    void init(bool* ptr) { notified = ptr; }
    ~GuardNotifier() { *notified = true; }
};
class GuardNotifyReceiver
{
    bool notified;
  public:
    GuardNotifyReceiver() : notified(false) { }
    void init(const GuardNotifier& notifier)
      { const_cast<GuardNotifier&>(notifier).init(&notified); }
    ~GuardNotifyReceiver() { assert(notified); }
};
class StateSaver
{
    GuardNotifyReceiver receiver;
  public:
    StateSaver(int i,
               const GuardNotifier& notifier = GuardNotifier())
    {
      receiver.init(notifier)
      saveState();
    }
    ~StateSaver()
    {
      restoreState();
    }
};