How to prevent an object being created on the heap?

Question

Does anyone know how I can, in platform-independent C++ code prevent an object from being created on the heap? That is, for a class "Foo", I want to prevent users from doing this:

Foo *ptr = new Foo;

and only allow them to do this:

Foo myfooObject;

Does anyone have any ideas?

Cheers,

Answer 1

Nick's answer is a good starting point, but incomplete, as you actually need to overload:

private:
    void* operator new(size_t);          // standard new
    void* operator new(size_t, void*);   // placement new
    void* operator new[](size_t);        // array new
    void* operator new[](size_t, void*); // placement array new

(Good coding practice would suggest you should also overload the delete and delete[] operators -- I would, but since they're not going to get called it isn't really necessary.)

Pauldoo is also correct that this doesn't survive aggregating on Foo, although it does survive inheriting from Foo. You could do some template meta-programming magic to HELP prevent this, but it would not be immune to "evil users" and thus is probably not worth the complication. Documentation of how it should be used, and code review to ensure it is used properly, are the only ~100% way.

Answer 2

You could overload new for Foo and make it private. This would mean that the compiler would moan... unless you're creating an instance of Foo on the heap from within Foo. To catch this case, you could simply not write Foo's new method and then the linker would moan about undefined symbols.

class Foo {
private:
  void* operator new(size_t size);
};

PS. Yes, I know this can be circumvented easily. I'm really not recommending it - I think it's a bad idea - I was just answering the question! ;-)

Answer 3

I don't know how to do it reliably and in a portable way.. but..

If the object is on the stack then you might be able to assert within the constructor that the value of 'this' is always close to stack pointer. There's a good chance that the object will be on the stack if this is the case.

I believe that not all platforms implement their stacks in the same direction, so you might want to do a one-off test when the app starts to verify which way the stack grows.. Or do some fudge:

FooClass::FooClass() {
    char dummy;
    ptrdiff_t displacement = &dummy - reinterpret_cast<char*>(this);
    if (displacement > 10000 || displacement < -10000) {
        throw "Not on the stack - maybe..";
    }
}

Answer 4

@Nick

This could be circumvented by creating a class that derives from or aggregates Foo. I think what I suggest (while not robust) would still work for derived and aggregating classes.

E.g:

struct MyStruct {
    Foo m_foo;
};

MyStruct* p = new MyStruct();

Here I have created an instance of 'Foo' on the heap, bypassing Foo's hidden new operator.

Answer 5

Because debug headers can override the operator new signature, it is best to use the ... signatures as a complete remedy:

private:
void* operator new(size_t, ...) = delete;
void* operator new[](size_t, ...) = delete;

Answer 6

You could declare a function called "operator new" inside the Foo class which would block the access to the normal form of new.

Is this the kind of behaviour you want ?

Answer 7

You could declare it as an interface and control the implementation class more directly from your own code.

Answer 8

this can be prevented by making constructors private and providing a static member to create an object in the stack

Class Foo
{
    private:
        Foo();
        Foo(Foo& );
    public:
        static Foo GenerateInstance() { 
            Foo a ; return a; 
        }
}

this will make creation of the object always in the stack.

Answer 9

Not sure if this offers any compile-time opportunities, but have you looked at overloading the 'new' operator for your class?