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

Question

Ich möchte sicherstellen, dass meine RAII-Klasse immer auf dem Stack zugewiesen wird.

Wie verhindere ich, dass eine Klasse über den "new"-Operator zugewiesen wird?

Answer 1

Alles, was Sie tun müssen, ist, den neuen Operator der Klasse als privat zu deklarieren:

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

Wenn man 'operator new' privat macht, wird verhindert, dass Code außerhalb der Klasse 'new' verwendet, um eine Instanz von X zu erzeugen.

Der Vollständigkeit halber sollten Sie "operator delete" und die Array-Versionen der beiden Operatoren ausblenden.

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

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: Ist es möglich, die Stack-Allokation eines Objekts zu verhindern und nur zuzulassen, dass es mit "new" instanziiert wird?

Answer 2

Ich bin von Ihrer Motivation nicht überzeugt.

Es gibt gute Gründe, RAII-Klassen im freien Handel zu erstellen.

Ich habe zum Beispiel eine RAII-Sperrklasse. Ich habe einen Pfad durch den Code, wo die Sperre nur notwendig ist, wenn bestimmte Bedingungen halten (es ist ein Videoplayer, und ich muss nur die Sperre während meiner Rendering-Schleife halten, wenn ich ein Video geladen und spielen habe; wenn nichts geladen ist, brauche ich es nicht). Die Möglichkeit, Sperren für den freien Speicher zu erstellen (mit einem unique_ptr ) ist daher sehr nützlich; es ermöglicht mir, denselben Codepfad zu verwenden, unabhängig davon, ob ich das Schloss herausnehmen muss.

d.h. etwa so:

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

Wenn ich nur Sperren auf dem Stapel erstellen könnte, könnte ich das nicht tun....

Answer 3

@DrPizza:

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

Wie auch immer, vielleicht ist ein besserer Weg, um Ihr Dilemma zu nähern ist, um einen Parameter zu Ihrer Sperre Konstruktor, der angibt, ob die Sperre benötigt wird hinzufügen. 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 notwendig ist, existiert die Mutex nicht einmal, so dass ich denke, dass dieser Ansatz eher schwieriger zu passen wäre.

Was ich wirklich nicht verstehe, ist die Rechtfertigung für das Verbot der Erstellung dieser Objekte im freien Speicher.