51

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?

Kevin
  • 25,207
  • 17
  • 54
  • 57

4 Answers4

60

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’?

Community
  • 1
  • 1
Kevin
  • 25,207
  • 17
  • 54
  • 57
  • 3
    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. – Richard Corden Sep 24 '08 at 07:44
  • 6
    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. – Konrad Rudolph Sep 24 '08 at 11:38
  • 4
    This doesn't prevent `X *x = ::new X;`, which explicitly calls the global operator new, not the class operator new... – Chris Dodd Nov 22 '16 at 22:27
  • 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. – Dave Ruske Apr 27 '17 at 04:34
7

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

ceztko
  • 14,736
  • 5
  • 58
  • 73
DrPizza
  • 17,882
  • 7
  • 41
  • 53
  • 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. – Kevin Sep 24 '08 at 05:37
  • 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(); – Kevin Sep 24 '08 at 05:41
  • 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. – Thomas Apr 21 '13 at 10:08
2

@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();
Kevin
  • 25,207
  • 17
  • 54
  • 57
0

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.

DrPizza
  • 17,882
  • 7
  • 41
  • 53
  • 1
    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). – Kevin Sep 24 '08 at 12:08