another preference question....
-
El Corazon wrote:
I was brought up (admittedly on books for C++, not college), that constructors not only construct, but initialize everything so that the class is "ready to be used" alternately the destructor removes everything and cleans up after itself. This way there is never an issue as far as timing when you use the contents of a class.
I agree. Otherwise, what's the point of having constructors/destructors? I would find it strange if I'm using an API in which I have to call "Initialize" on an object before I can use it. Regarding destructors, I program mainly with C# now, and I miss the deterministic and automatic destruction mechanism of C++. Instead, I must remember to call
Disposewhere it is implemented. It seems rather procedural rather than object oriented to have to remember to call "Initialize/Cleanup" on objects rather than letting the constructor/destructor handle that for you. Having said that, sometimes it's necessary to establish the relationships between objects after they've been created. This is particularly true when you must have a parameterless constructor for whatever reason. Once an object is created, you can then establish its relationship with other objects by using its setters to set its properties. However, even in those situations, it's helpful if the object behaves normally regardless of whether any of its properties have been set. The "Null Object" design pattern can be helpful here.exactly: and in easier terms. constructor and the destructor or for memory management. init() is for class that have to many properties to pass in as arguments. unless you won't to use a config file/mem and decipher. ounces the object is constructed ,even if all it does is initialize the object to a NULL state, then you can set properties and call Init() ,the destructor in where you clean up,even if you got to call special function from the destructor, to keep the code clean.
-
Just curious. Had this disagreement with my team a while back and lost. I didn't want to bring it up then as it would be pointless. But I am curious on a design issue with classes. I was brought up (admittedly on books for C++, not college), that constructors not only construct, but initialize everything so that the class is "ready to be used" alternately the destructor removes everything and cleans up after itself. This way there is never an issue as far as timing when you use the contents of a class. Others have promoted an init()/configure() methodology and cleanup()/clear() so that constructors construct the class, not the content, init()/configure() sets up the content, cleanup()/clear() removes the content (which I have used for specific reusable storage type classes, but never as a hard rule of everything) and destructor pretty much does nothing unless memory allocation is involved. Of course this also means, if threads are involved there requires an additional start() after configure() to get the ball rolling which creats a set of "do this first directives" in the documentation. :~ I do freely admit no college training, not sure if this is a college thing or not. I am not a lover of absolutes, but I did always like my classes clean so that they start and stop by scope properly (everything handled by constructors and destructors), and now I find myself staring at my code as if it is growing green, black and white mold with the recent changes to it. X| Is this a college teaching method? Have I been putting too much effort into organizing my classes as independant entities?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
I believe the primary reason for this separation (which a few people have already suggested or hinted at) is that you can do something in your Init() function that you can't do in your constructor. Namely, you can call virtual functions and expect them to operate correctly! You can't do this in a constructor. To quote Scott Meyers in Effective C++: "You shouldn't call virtual functions during construction or destruction, because the calls won't do what you think, and if they did, you'd still be unhappy". You can read more about this at http://www.artima.com/cppsource/nevercall.html[^]. I have a friend who worked at a company that got so badly burned by bugs related to calling virtual functions from constructors, that they completely banned the use of constructors in all of their C++ code! This seems an extreme solution to me, but you get the point. To my mind constructors should be used to perform "simple" initialization -- initialize data members, allocate some memory, load resource strings, etc. If you need to do very complex initialization that involves calling other functions, then there may be an argument for breaking this out into a separate Init() function. If your initialization involves calling virtual functions, then it must be broken out into an Init() function to ensure it works reliably. Similar arguments would apply to destructors. Rob.
-
pbraun wrote:
There are very valid reasons to use them outside of the constructor as well
I think the term 'as well' qualifies it really. IMHO it's fine to call the init() outside of the constructor as well, but seems foolish to not to call it at construct time - even if all it does is initialise the object to a NULL state.
It is useful to initialize simple member variables in a constructor. However, if the class that is being constructed needs to instantiate other objects (such as COM components or additional non-trivial classes or additional threads) then doing those kinds of operations in the constructor can cause major problems since the parent class is not yet completely formed. sweetpickle
-
Just curious. Had this disagreement with my team a while back and lost. I didn't want to bring it up then as it would be pointless. But I am curious on a design issue with classes. I was brought up (admittedly on books for C++, not college), that constructors not only construct, but initialize everything so that the class is "ready to be used" alternately the destructor removes everything and cleans up after itself. This way there is never an issue as far as timing when you use the contents of a class. Others have promoted an init()/configure() methodology and cleanup()/clear() so that constructors construct the class, not the content, init()/configure() sets up the content, cleanup()/clear() removes the content (which I have used for specific reusable storage type classes, but never as a hard rule of everything) and destructor pretty much does nothing unless memory allocation is involved. Of course this also means, if threads are involved there requires an additional start() after configure() to get the ball rolling which creats a set of "do this first directives" in the documentation. :~ I do freely admit no college training, not sure if this is a college thing or not. I am not a lover of absolutes, but I did always like my classes clean so that they start and stop by scope properly (everything handled by constructors and destructors), and now I find myself staring at my code as if it is growing green, black and white mold with the recent changes to it. X| Is this a college teaching method? Have I been putting too much effort into organizing my classes as independant entities?
_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
After following this discussion I come back to something that has been bothering me for some years now. Where is the good old top down method of programming where there were no classes and you solved everything with a gosub and a goto. These arcane problems with classes never came up then. And even back then, the programs still worked. Chris