Czy można zapobiec powstawaniu "anonimowo" klasy w stylu RAII?

Question

Załóżmy mam RAII stylu C++ Klasa:

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

... być używane tak jak w moim kodu:

void Manipulate() 
{ 
    StateSaver save(1); 

    // ...do stuff that modifies state 
} 

... celem jest, aby podać stan, zrobić rzeczy, a następnie opuść ten stan, kiedy opuszczę ten zakres. Czy istnieje sposób, aby ten błąd nie został skompilowany (lub ostrzec, lub jakoś narzekać, aby błąd został zauważony)?

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

    // ...do stuff that modifies state 
} 

Nie jestem świadomy czegokolwiek w C++, którego mogłem użyć, aby temu zapobiec, ale to nie znaczy, że nie istnieje. Jeśli nie ma niczego w C++, dopuszczalne są rozszerzenia specyficzne dla kompilatora. Interesuje mnie przede wszystkim cokolwiek skierowane na gcc i msvc (kiedyś icc, pomysły na inne kompilatory mile widziane, ale mniej prawdopodobne, że będą użyteczne), więc przydatne byłoby hackowanie któregokolwiek z nich (wyodrębnione odpowiednio # ifdef'd definicji makr) .

Answer 1

I rzeczywiście musiał dostosować my solution w pęczek względami od wariantu Waldo pisał, ale co ja w końcu dostałem się to makro-ized wersja:

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(); 
    } 
}; 

Answer 2

SaveMatrix save(); nie definiuje również obiektu. Deklaruje funkcję.

Niewiele można zrobić, aby uniemożliwić innym (lub tobie, FTM) robienie czegoś innego niż oni chcieli. Jedyne, o czym mogę pomyśleć, to nie pisanie samego kodu, ale zamiast tego pisanie makra.

Jest to jednak dość brzydkie. OTOH, przechwytuje błąd podczas kompilacji.

Answer 3

Nie jestem pewien, czy cokolwiek można zrobić podczas kompilacji. Na czeku run-time, można to zrobić:

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

który wymaga klienta, aby napisać:

SaveMatrix sm(sm); 

i nie ma sposobu, aby zrobić to samo dla tymczasowy bez wiązania go do identyfikatora (w którym to momencie nie różni się od zmiennej automatycznej).

Answer 4

Klasa nie może stwierdzić, czy została utworzona jako tymczasowa (SaveMatrix()), czy jako zmienna (SaveMatrix save;). Myślę, że najlepszym sposobem, aby zatrzymać programator robi to bez stosu lub hacki makro jest wymusić wywołanie funkcji członek po budowie, np

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

    void Do() 
    { 
     valid = true; 
    } 

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

to wtedy działa następująco:

{ 
    // 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; 
}