classes needed to learn
I need some well designed, small tutorial-like C++ class to study their concepts.
I'm looking for an almost general way of defining my classes regarding construction/destruction, tracking object's "life-states" (IsEmpty(), Delete() etc.). I have to know what has to be put where and I also want to avoid double-definitions of methods (for example in some cases MakeEmpty() seems to be the same as ~CMyClass(), in others they do not). I don't have a realy usable template for this, but I belive someone else has.
One of my problems is: can I use my ~CMyClass() to make my object empty or it's an unacceptable style. (for ex. in the = operation's definition before we assign the new values, can I call my destructor?)
[edited by - xropi on October 16, 2002 9:50:29 AM]
Hmm, that''s a bit of a strange question, honestly. Because by concept a C++ class is an abstract object, and needen''t have states.
Personally, I find C++ OO programming most useful to encapsulate code (making it easier to debug and alter programs) and polymorphism gives one impressive flexibility, but I digress...
''Tracking object''s "Life-state"'': As I said, an object does not need to be a state machine. If it is, the fact that it''s a C++ class is unrelated to the state machine. An exception would be if you created an object via new and then deleted it... Then the object no longer exists! You can''t even access it without a major run-time error.
''in some cases MakeEmpty() seems to be the same as ~CMyClass(), in others they do not'': Agreed, that''s one of my pet peeves with DirectX interfaces, having to call ::Release() most everytime. I will give the advise that Scott Meyers recommends: The best object is one that works well after its constructor is called (i.e. when it exists) and one that cleans itself up in its destructor alone. Then you haven''t to ask yourself questions about ''Should I call ::Release()?''.
Of course we''re programming in DirectX quite often, an ''Init()'' loop is almost unavoidable *le sigh*.
''can I use my ~CMyClass() to make my object empty?'': It''s not an ''unacceptable style'', in fact since a destructor is supposed to clear up all dynamic memory of an object and programming is about not coding the same thing twice, it is the perfect function call to make to clean up an object.
=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.
Personally, I find C++ OO programming most useful to encapsulate code (making it easier to debug and alter programs) and polymorphism gives one impressive flexibility, but I digress...
''Tracking object''s "Life-state"'': As I said, an object does not need to be a state machine. If it is, the fact that it''s a C++ class is unrelated to the state machine. An exception would be if you created an object via new and then deleted it... Then the object no longer exists! You can''t even access it without a major run-time error.
''in some cases MakeEmpty() seems to be the same as ~CMyClass(), in others they do not'': Agreed, that''s one of my pet peeves with DirectX interfaces, having to call ::Release() most everytime. I will give the advise that Scott Meyers recommends: The best object is one that works well after its constructor is called (i.e. when it exists) and one that cleans itself up in its destructor alone. Then you haven''t to ask yourself questions about ''Should I call ::Release()?''.
Of course we''re programming in DirectX quite often, an ''Init()'' loop is almost unavoidable *le sigh*.
''can I use my ~CMyClass() to make my object empty?'': It''s not an ''unacceptable style'', in fact since a destructor is supposed to clear up all dynamic memory of an object and programming is about not coding the same thing twice, it is the perfect function call to make to clean up an object.
=^.^= Leaders and teachers should remember: It is best to offer others what they Need, not what they Want.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement