another preference question....

El Corazon

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)

led mike

Well there is nothing wrong with breaking that out like that as long as they are then called from constructors,destructors, assignment operators etc.

pbraun

The main reason that separate methods are used for initialization and cleanup is for easier debugging purposes. There are too many times when a bug is found in the constructor or destructor after many painful hours of debugging. Using the separate methods allows one to isolate those points more easily. Having stated that, I firmly believe that all variables should be initialized before first use, unless the first use is to initialize them and therefore I still use the constructor to give the variables of the class an initial value as much as is reasonable. In doing this my code always has a known starting point.

Phil

Judah Gabriel Himango

I've found consuming code to be much cleaner if constructors make the class ready for use. In other words, if the class can't really be used unless the Foobar property is set to something, then the constructor should take an instance of Foobar and set it. I often combine this idea with C#'s readonly modifier; it guarantees the field doesn't change after construction. Fewer changing things means validation needs to be done only once. Consumers can assume everything's in the right state and ready to be used, making that code cleaner. As far as college training goes, I don't recall ever being taught this in my C++ courses at college. Either they didn't teach it or I just don't remember. :) Probably the latter.

Tech, life, family, faith: Give me a visit. I'm currently blogging about: Just F-ing Do It :) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango

El Corazon

led mike wrote:

Well there is nothing wrong with breaking that out like that as long as they are then called from constructors,destructors, assignment operators etc.

nope, called from outside.... myclass = new aclass(...); myclass->init(); myclass->start(); // if threads myclass->stop(); // if threads myclass->clear(); delete(myclass);

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

Leslie Sanford

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 Dispose where 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.

Jorgen Sigvardsson

I don't buy your "harder to debug" argument. Which debugger won't allow you to step inside constructors? :~

-- Raaaaaaaaaaaaaaaaaaaaa!

El Corazon

Judah Himango wrote:

I've found consuming code to be much cleaner if constructors make the class ready for use. In other words, if the class can't really be used unless the Foobar property is set to something, then the constructor should take an instance of Foobar and set it.

That has always been the way I have done it. I just thought that was the purpose of the constructor.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)

Lost User

El Corazon wrote:

Others have promoted an init()/configure() methodology

Yuck - and every C++ book I have read agrees with _you_ - all initialization should be done in the constructor. OK, the constructor might call some 'init' function (shared by multiple constructors for example), but once constructed, the object should be ready to use and any resources it needs should of been acquired. Having to call some init function after the object has been created sounds like something someone from a 'C' background might be comfortable with, but I think you are quite correct and should stick to your guns. I am also studying for a degree where Java is the language of choice and the same thing is taught. I recommend you check out this[^] book (C++ Coding Standards by Herb Sutter and Andrei Alexandrescu) - it is full of stuff like this.

Kicking squealing Gucci little piggy.
The Rob Blog

Craster

Unless there's any instance where you might want to instantiate the class without initialising it, that's a ludicrous waste of time.

Jorgen Sigvardsson

IMO, it boils down to this: 1) If the object is a first class entity - i.e., not a handle - then do initialization and finalization in constructor and destructor 2) If the object is a simple handle (such as a CWnd derivative), then there are two life lines - the handle object itself and whatever it's handling. Then I use init()/cleanup() to handle the life line of the handled object. My reason for 2) is that the destruction of handled object may fail - something I don't want to deal with in a destructor (if you say exception, then you've not only shot yourself in the foot, but you've also blown your brains out). Also, I might want to be able to share the handled object between handles, or I might just want to transfer the responsibility of it elsewhere. Note that this isn't something I've learned in school. I've picked it up as I go... :)

-- Raaaaaaaaaaaaaaaaaaaaa!

Nemanja Trifunovic

El Corazon wrote:

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.

That idiom is called "two-phase construction" and was widely used before exceptions were available for C++. For instance, MFC uses it all the time simply because VC++ didn't support exceptions at the time that MFC was designed. In general, today most experts including Stroustrup recommend avoiding two-phase construction, but some people don't use exceptions for one reason or another and they really have little choice: constructors can't return values to tell us if something went wrong :)

Programming Blog utf8-cpp

Chris Losinger

i prefer to avoid init/cleanup methods. but it typically happens that i'll get the urge to put my objects into STL containers, and find i need to move the cleanup code out of the dtor because some member variable is dynamically-allocated - if i let the dtor handle cleanup, it would free that data on the first copy operation and then all copies would have pointers to junk. i suppose this is why they invented auto_ptr and friends

image processing toolkits | batch image processing | blogging

pbraun

Joergen Sigvardsson wrote:

"harder to debug"

The issue isn't whether or not it is "harder to debug", but about isolation of the initialization or cleanup from the construction or destruction of the class.

Phil

Andy Brummer

I think the init() concept ranks up there with initialization through property setters. X| Initialization in the constructor means that you can't have access to the object from outside code until the constructor completes unless you are doing something like an inplace new. Plus one of the biggest sources of C++ bugs is not calling delete, now you've just added this potential to stack allocated objects too. It's even worse for mutlithreaded code since you are just introducing the possibility of extra race conditions. So, I'd just require that every object with the init and clear methods implement 2 static methods:

object* Construct()
{
object* obj = new object();
obj->init();
return obj;
}

void Destruct(object* obj)
{
obj->clear();
delete obj;
}

Either that or add a init_ptr<> smart pointer class.

This blanket smells like ham

Patrick Etc

pbraun wrote:

The main reason that separate methods are used for initialization and cleanup is for easier debugging purposes. There are too many times when a bug is found in the constructor or destructor after many painful hours of debugging. Using the separate methods allows one to isolate those points more easily.

Ok. Make them separate methods and call them inside the constructor. Yes? I do this all the time. I prefer my objects to start with a known state than wonder if some method has been called yet.

Dario Solera

Leslie Sanford wrote:

Instead, I must remember to call Dispose where it is implemented.

Not really needed if the object does not consumes lots of memory... Dispose/Finalize is invoked automatically (but not necessarily immediately) when the instance goes out of scope.

If you truly believe you need to pick a mobile phone that "says something" about your personality, don't bother. You don't have a personality. A mental illness, maybe - but not a personality. - Charlie Brooker My Blog - My Photos - ScrewTurn Wiki

Leslie Sanford

Joergen Sigvardsson wrote:

IMO, it boils down to this: 1) If the object is a first class entity - i.e., not a handle - then do initialization and finalization in constructor and destructor 2) If the object is a simple handle (such as a CWnd derivative), then there are two life lines - the handle object itself and whatever it's handling. Then I use init()/cleanup() to handle the life line of the handled object. My reason for 2) is that the destruction of handled object may fail - something I don't want to deal with in a destructor (if you say exception, then you've not only shot yourself in the foot, but you've also blown your brains out). Also, I might want to be able to share the handled object between handles, or I might just want to transfer the responsibility of it elsewhere. Note that this isn't something I've learned in school. I've picked it up as I go...

Hmm, interesting viewpoint. As someone who's written a lot of "wrapper" classes, I find your approach interesting. I'll have to give it some thought.

pbraun

Patrick Sears wrote:

call them inside the constructor

There are very valid reasons to use them outside of the constructor as well. When one is developing the class, one needs to be clear as to the reasons why the constructor and destructors are separate.

Phil

El Corazon

Nemanja Trifunovic wrote:

and was widely used before exceptions were available for C++.

the advantage of me learning from books later in the game. :laugh: Actually, that explains a lot. Thanks.

_________________________ Asu no koto o ieba, tenjo de nezumi ga warau. Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)