tags:

views:

987

answers:

7

Does anyone know how I can, in platform-independant 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,

A: 

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 ?

David
+5  A: 

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

Nick
A: 

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

Will Dean
+2  A: 

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..";
    }
}
pauldoo
Interesting approach!
hackworks
I think that this and dummy will always be close to each other no matter if they are in the heap or in the stack
Vargas
@Vargas - I disagree. 'dummy' will always be on the stack, because it is an automatic local variable. The `this` pointer can point to either the stack (if FooClass is used as a local variable) or the heap (if FooClass is allocated on the heap, or aggregating within a class which is then allocated on the heap).
pauldoo
You are right, I was mistaking `dummy` for a member variable... sorry
Vargas
+2  A: 

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

pauldoo
A: 

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

Lasse V. Karlsen
+8  A: 

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.

Patrick Johnmeyer