Skip to main content
GameDev.net gamedev.net
🔒 Locked

Heap-only objects

Started by cannonicus Nov 10, 2004 at 10:17 AM 17 replies 1.4k views
Original Post
cannonicus
cannonicus
Hi is there some way to make classes in c++ impossible to create on the stack but not on the heap? Like this: class Foo{}; Foo f; //make impossible int main() { Foo* pf = new Foo; //still be possible return 0; } Grateful for answers
Emil Jonssonvild
Agony
Agony
Making the constructor private, I believe, will do the trick. [edit]And then making a static member function that creates the object.[/edit]

class CHeapOnly{  public:    static CHeapOnly* Create() { return new CHeapOnly; }  private:    CHeapOnly() {}};int main(){  CHeapOnly* pHeapOnly = CHeapOnly::Create();  delete pHeapOnly;  return 0;}
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o
Jingo
Jingo
It has a number of flaws

class CHeapOnly{  public:    static CHeapOnly* Create() { return new CHeapOnly; }  private:    CHeapOnly() {}};int main(){  CHeapOnly* pHeapOnly = CHeapOnly::Create();  CHeapOnly itsonthestack(*pHeapOnly);  delete pHeapOnly;  return 0;}


operator new could also be overloaded to allocate from a stack based resource.
cannonicus
cannonicus
Ok but is there any other way to do the same thing

And what happens if you derive a class from CHeapOnly? didnt work for me.
Emil Jonssonvild
Jingo
Jingo
Making the constructor and copy constructor protected should allow you to derive from it.
Jingo
Jingo
Making them protected, though, would allow others to derive from it and ignore the static heap allocating function, and allocate on the stack.
Agony
Agony
From what I have gathered, compiler protections such as private and protected members, and const variables, etcetera, can always be circumvented if someone really wants to. These features don't exist to force malevolent programmers to do what they're suppose to; they exist to help point out when innocent, good-intentioned programmers make a mistake.

The level of perfection and strength that is needed, I suppose, is based on the intended use. I guess there may be times that you want to make it as almost impossible to do something against the intended rules. But most of the time, it's not that critical. So I guess my question is to the OP: What's this for?

(In fact, after answering the question, I realized that it might simply be for homework, and I shouldn't have just thrown out a solution (perfect or imperfect) without checking first. Oh well.)
"We should have a great fewer disputes in the world if words were taken for what they are, the signs of our ideas nly, and not for things themselves." - John Locke o
Jingo
Jingo
Quote:
Original post by Agony
From what I have gathered, compiler protections such as private and protected members, and const variables, etcetera, can always be circumvented if someone really wants to. These features don't exist to force malevolent programmers to do what they're suppose to; they exist to help point out when innocent, good-intentioned programmers make a mistake.

The level of perfection and strength that is needed, I suppose, is based on the intended use. I guess there may be times that you want to make it as almost impossible to do something against the intended rules. But most of the time, it's not that critical. So I guess my question is to the OP: What's this for?

(In fact, after answering the question, I realized that it might simply be for homework, and I shouldn't have just thrown out a solution (perfect or imperfect) without checking first. Oh well.)


True, which is another reason as to why making it only heap based is impossible.
cannonicus
cannonicus
This is NOT for homework. We dont event not what a heap is in my class, and i doubt thats even part of our cours.

Anyways, im working on a sidescroller lierostyle game. This heap-only class is to be used in my sprite-baseclass so that sprite classes wont be created before the main function. DirectX would in that case not have been loaded properly and the sprites, trying to create dx-surfaces, would cause errors when trying to use directx without a directx-interface.

Maybe(probably) theres another better way solve this problem, like haveing all dx-dependent code in a separate sprite function called in the main-loop instead of haveing it in the constructors. But it is always best to ask...

Feedback plz.

Emil Jonssonvild
Polymorphic OOP
Polymorphic OOP
Quote:
Original post by Jingo
True, which is another reason as to why making it only heap based is impossible.

What about having the user only able to interact with the object via an ABC without knowledge of the true type of the object, only it's base? The user can't derive from the class since it doesn't even know what the type is, since it can either be in a DLL, or a module he doesn't know about, or it could be a nested class private to another class making it innaccessible, etc.
Jingo
Jingo
Quote:
Original post by Polymorphic OOP
Quote:
Original post by Jingo
True, which is another reason as to why making it only heap based is impossible.

What about having the user only able to interact with the object via an ABC without knowledge of the true type of the object, only it's base? The user can't derive from the class since it doesn't even know what the type is, since it can either be in a DLL, or a module he doesn't know about, or it could be a nested class private to another class making it innaccessible, etc.


What about it?
Polymorphic OOP
Polymorphic OOP
Quote:
Original post by Jingo
What about it?

I'm just saying that's one way to ensure that an object is allocated in the manner you wish. IE You generally can't choose how to allocate a COM object, since you don't even have access to the class type, only the interface type, and the allocation and deallocation is done in a separate module.
Jingo
Jingo
Wouldn't be portable.
cannonicus
cannonicus
What do you think of haveing something like this in the baseclass constructor:

if(!_CrtIsValidHeapPointer(this)) throw 0;

?
Emil Jonssonvild
Zahlman
Zahlman
That would fail at runtime, and therefore not solve your problem.
iMalc
iMalc
Quote:
Original post by cannonicus
This is NOT for homework. We dont event not what a heap is in my class, and i doubt thats even part of our cours.

Anyways, im working on a sidescroller lierostyle game. This heap-only class is to be used in my sprite-baseclass so that sprite classes wont be created before the main function. DirectX would in that case not have been loaded properly and the sprites, trying to create dx-surfaces, would cause errors when trying to use directx without a directx-interface.

Maybe(probably) theres another better way solve this problem, like haveing all dx-dependent code in a separate sprite function called in the main-loop instead of haveing it in the constructors. But it is always best to ask...

Feedback plz.
From your description thye problem has nothing to do with where the memory is allocated, but simply WHEN it is allocated.
If it must be allocated after DX then all you have to do is dynamically allocate it after your DX stuff. i.e. don't make the objects themselves global, instead have a global pointer to them. I don't see why it's so hard to solve, unless there's something I'm missing?
mattnewport
mattnewport
Scott Meyers discusses ways of trying to make classes that can only be constructed on the stack and classes that can only be constructed on the heap in Effective C++ (or possibly More Effective C++, I'm not sure). In the end I think he concludes that it is not possible in a completely robust manner but he offers a number of partial solutions which may be 'good enough' in many situations.

I can highly recommend these two books - there's lots of useful information in them beyond the item(s) on controlling allocation.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.