CObject *obj = new Derived; Base class constructors/destructors.
Author
I have this base class called CObject.
it is basically for my game engine, so the pure virtual functions I have is Render(...), and thats about it.
First of all, I noticed that any derived class from CObject
like this:
...doesn''t call it''s destructor when i delete it, even though the constructor is called.
So the question(s):
1) how do i get constructors and destructors to work in derived classes??
2) what other methods would be useful in a game-based Base class like CObject?
hmm. Here''s some advice. Learn C++. Learn OO. Then realize what you did wrong. The reference section is full of stuff to help you learn.
Please. I''m not trying to put you down. Just that if you can''t udnerstand what you''re doing wrong or how to fix it you really need to properly learn C++. Consider this a wake up call.
Please. I''m not trying to put you down. Just that if you can''t udnerstand what you''re doing wrong or how to fix it you really need to properly learn C++. Consider this a wake up call.
1) put a virtual destructor in CObject-class
2) is CObject really necessary? Does it give any benefits to you? If not, get rid of CObject and don''t inherit just for the sake of inheritation. It''s highly likely that your CObject is useless, from what you''ve described.
2) is CObject really necessary? Does it give any benefits to you? If not, get rid of CObject and don''t inherit just for the sake of inheritation. It''s highly likely that your CObject is useless, from what you''ve described.
Civguy, 2)
Of course that is useful! You can have a list of CObject* that actually contains cubes, triangles, pyramids, or whatever.
"No lies of sugar can sweeten the sournes of reality"
}+TITANIUM+{ A.K.A. DXnewbie[onMIRC]
Of course that is useful! You can have a list of CObject* that actually contains cubes, triangles, pyramids, or whatever.
"No lies of sugar can sweeten the sournes of reality"
}+TITANIUM+{ A.K.A. DXnewbie[onMIRC]
Author
It may not be necessary to have CObject.
but it will make things cleaner and easier to read since i can have a list of these CObjects and call its Render() function straight thru the list.
I tried a virtual constructor and virtual destructor (both were pure virtual). I had problems compiling the pure virtual destructor though. I''ll try again.
Also, are the following equivocal?
but it will make things cleaner and easier to read since i can have a list of these CObjects and call its Render() function straight thru the list.
I tried a virtual constructor and virtual destructor (both were pure virtual). I had problems compiling the pure virtual destructor though. I''ll try again.
Also, are the following equivocal?
// one wayCObject *obj = new Derived;// second wayDerived *derived = new Derived;CObject *obj = derived;
Yeah try a virtual destructor:
virtual ~CObject(); (i think)
That should work if inheritance is involved
-----
Losec
-----
virtual ~CObject(); (i think)
That should work if inheritance is involved
-----
Losec
-----
quote:Original post by GekkoCubeConstructor can''t be virtual. If destructor is pure virtual, it still needs to be defined (it''s a special virtual function). Like this:
I tried a virtual constructor and virtual destructor (both were pure virtual). I had problems compiling the pure virtual destructor though. I''ll try again.
struct A { virtual ~A() = 0;};A::~A() {} But if Render() is already pure virtual, you don''t need to make the destructor pure virtual in order to make the class abstract.
quote:Also, are the following equivocal?
Yes.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
