How do I prevent a class from being allocated via the 'new' operator? (I'd like to ensure my RAII class is always allocated on the stack.)

Question

I'd like to ensure my RAII class is always allocated on the stack.

How do I prevent a class from being allocated via the 'new' operator?

Mckenna

Answer 1

All you need to do is declare the class' new operator private:

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

Making 'operator new' private effectively prevents code outside the class from using 'new' to create an instance of X.

To complete things, you should hide 'operator delete' and the array versions of both operators.

Since C++11 you can also explicitly delete the functions:

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

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

Mckenna

Another point is that this only stops 'new' being called from outside of the class hierarchy. ie. it is possible for a member of 'X' to call the funciton. The new C++ '0x feature "=delete" will allow you to explicitly stop the function from ever being called. – Butlery

Richard, no, these methods can never be called because they're only declared but not defined. The difference is that private access will yield a linker error rather than a compiler error. – Aconcagua

This doesn't prevent X *x = ::new X;, which explicitly calls the global operator new, not the class operator new... – Indeclinable

There is at least one reason why it may be preferable to give static void *operator new (size_t) = delete and friends private access: it may keep them from appearing in code completion in your IDE. – Quass

Answer 2

I'm not convinced of your motivation.

There are good reasons to create RAII classes on the free store.

For example, I have an RAII lock class. I have a path through the code where the lock is only necessary if certain conditions hold (it's a video player, and I only need to hold the lock during my render loop if I've got a video loaded and playing; if nothing's loaded, I don't need it). The ability to create locks on the free store (with an unique_ptr) is therefore very useful; it allows me to use the same code path regardless of whether I have to take out the lock.

i.e. something like this:

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

If I could only create locks on the stack, I couldn't do that....

Shagreen

An interesting point. For that I give you +1. Note though that there are some situations where the RAII idiom isn't necessarily optional. Anyway, perhaps a better way to approach your dilemma is to add a parameter to your lock constructor that indicates whether the lock is needed. – Mckenna

For example: class lock { mutex& m; bool dolock; public: lock(mutex& m_, bool dolock_) : m(m_), dolock(dolock_) { if (dolock) m.lock(); } ~lock() { if (dolock) m.unlock(); } }; Then you could write: lock l(mtx, needs_lock); render(); – Mckenna

A case where preventing new is essential: if your RAII class internally maintains a static stack of all live objects of that class, and assumes that objects of the class are destroyed in reverse order in which they are created. I'm using this to maintain OpenGL state, as a replacement for the deprecated glPushAttrib/glPopAttrib functions. – Slippage

Answer 3

@DrPizza:

That's an interesting point you have. Note though that there are some situations where the RAII idiom isn't necessarily optional.

Anyway, perhaps a better way to approach your dilemma is to add a parameter to your lock constructor that indicates whether the lock is needed. For example:

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

Then you could write:

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

Mckenna

Answer 4

In my particular situation, if the lock isn't necessary the mutex doesn't even exist, so I think that approach would be rather harder to fit.

I guess the thing I'm really struggling to understand is the justification for prohibiting creation of these objects on the free store.

Shagreen

The justification is that this is simply a way to help enforce a rule so that the next developer that comes doesn't accidentally do something like forget to delete a lock (which would cause a lockup). – Mckenna

Answer 5

A question arose in my mind as to whether the deleted static new/delete operators would also prevent derived classes from being allocated.

The answer (yes) now seems obvious, these methods are inherited by the derived class and thus are also deleted there.

A derived class could add its own definitions of non-deleted new/delete operators, in which case the derived class could be allocated.

Enlightenment