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?

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.

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

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 a scoped_ptr/auto_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:

auto_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....

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

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.