How can I tell if an object is statically or dynamically allocated on the constructor?

Question

I have an object that requires a slightly different construction wether it's instance is staticly or dynamically allocated. The object should only have a single default constructor. So having two constructors, one for each case, and having the user explicitly select the proper constructor is out of the question.

Is there any proper way to acheive this?

That's how I do this at the moment: I overload the new operator for that object, malloc the memory, and use the returned pointer as a pointer to the (yet un-initialized) instance, and set a specific data member of the object to some magic-value. Then, within the consutrctor, I check the value of the member. If it's the magic-value, then the object is 99.9% dynamically allocated.

This method haven't yet failed for me under either relase and debug modes, however, it seems like a terrible hack.

Answer 1

There's not really a portable way to do this.

Why do you want to, anyway? Seems like a design problem......

Answer 2

Overloading new sounds like a reasonable thing to do. I can't see another way of doing it.

Answer 3

As you allude to in your question, this method isn't guaranteed to work; what if the data member, by sheer chance, has the magic value?

There is no portable way to do what you want. You have to either live in fear and uncertainty or change your design. Sorry.

Answer 4

Any constructor can be used for static or dynamic allocation. There is no way for you to force the user of the object to use a particular constructor, whichever way he allocates the object.

Answer 5

You should be able to achieve what you want while leaving a single user-accessible default constructor (which will be used for static and auto objects -- you appear to ignore the existence of auto objects, e.g. local variables, so I imagine you want to treat these cases the same).

Make operator new and a separate constructor both private, and make a public static method (it's a case of the "factory method" design pattern) which only does a return new TheClass(123); (assuming the separate constructor takes for example an integer, but of course you can pick any type of argument you want, as the argument isn't used anyway).

You know you said the object should have a single constructor, but from the user's point of view that's exactly of the class is behaving, and there's no "explicit selection of constructor" on the user's part (he just can't call new explicitly but must go through your supplied factory method, that's all).

Answer 6

I don't think you can tell in the constructor.

I don't know if this helps, but you can prevent the object from being statically created by making the destructor private. You would also need to have a public "Delete" method that does a delete this for code that dynamically allocates objects of this class -- they would have to do an obj->Delete() rather than delete obj.