Wie verhindere ich, dass eine Klasse über den "neuen" Operator zugewiesen wird? (Ich möchte sicherstellen, dass meine RAII-Klasse immer auf dem Stapel zugeordnet ist.)

Question

Ich möchte sicherstellen, dass meine RAII-Klasse immer auf dem Stapel zugeordnet ist.

Wie verhindere ich, dass eine Klasse über den 'neuen' Operator zugewiesen wird?

Answer 1

Alles, was Sie tun müssen, ist die Klasse private neuen Betreiber:

class X 
{ 
    private: 
     // Prevent heap allocation 
     void * operator new (size_t); 
     void * operator new[] (size_t); 
     void operator delete (void *); 
     void operator delete[] (void*); 

    // ... 
    // The rest of the implementation for X 
    // ... 
}; 

Herstellung ‚erklären Betreiber neue‘ Private verhindert effektiv Code außerhalb der Klasse verwenden ‚neuen‘ eine Instanz von X erstellen

Um die Dinge abzuschließen, sollten Sie "Operator löschen" und die Array-Versionen beider Operatoren ausblenden.

Da C++ 11 Sie können explizit löschen auch die Funktionen:

class X 
{ 
// public, protected, private ... does not matter 
    static void *operator new  (size_t) = delete; 
    static void *operator new[] (size_t) = delete; 
    static void operator delete (void*) = delete; 
    static void operator delete[](void*) = delete; 
}; 

Verwandte Frage:Is it possible to prevent stack allocation of an object and only allow it to be instiated with ‘new’?

Answer 2

Ich bin von Ihrer Motivation nicht überzeugt.

Es gibt gute Gründe, RAII-Klassen im Free Store zu erstellen.

Zum Beispiel habe ich eine RAII Lock-Klasse. Ich habe einen Pfad durch den Code, wo die Sperre nur notwendig ist, wenn bestimmte Bedingungen erfüllt sind (es ist ein Videoplayer, und ich muss die Sperre nur während meiner Renderschleife halten, wenn ich ein Video geladen und abgespielt habe; wenn nichts geladen ist, Ich brauche es nicht). Die Möglichkeit, Sperren im Free Store (mit einem scoped_ptr/auto_ptr) zu erstellen, ist daher sehr nützlich. es erlaubt mir, denselben Codepfad zu verwenden, unabhängig davon, ob ich das Schloss herausnehmen muss.

also etwa so:

auto_ptr<lock> l; 
if(needs_lock) 
{ 
    l.reset(new lock(mtx)); 
} 
render(); 

Wenn ich nur Sperren auf dem Stapel erstellen konnte, konnte ich das nicht tun ....

Answer 3

@DrPizza:

Das ist ein interessanter Punkt, den Sie haben. Beachten Sie jedoch, dass es Situationen gibt, in denen das RAII-Idiom nicht unbedingt optional ist.

Wie auch immer, ein besserer Weg, Ihrem Dilemma zu begegnen, ist, einen Parameter zu Ihrem Lock-Konstruktor hinzuzufügen, der anzeigt, ob die Sperre benötigt wird. Zum Beispiel:

class optional_lock 
{ 
    mutex& m; 
    bool dolock; 

public: 
    optional_lock(mutex& m_, bool dolock_) 
     : m(m_) 
     , dolock(dolock_) 
    { 
     if (dolock) m.lock(); 
    } 
    ~optional_lock() 
    { 
     if (dolock) m.unlock(); 
    } 
}; 

Dann könnten Sie schreiben:

optional_lock l(mtx, needs_lock); 
render(); 

Answer 4

In meiner speziellen Situation, wenn die Sperre nicht der Mutex nicht einmal nicht notwendig ist, vorhanden ist, so denke ich, dass Ansatz wäre eher schwerer zu passen.

Ich denke, die Sache, die ich wirklich zu kämpfen habe, ist die Rechtfertigung für das Verbot der Schaffung dieser Objekte im freien Geschäft.