#### Archived

This topic is now archived and is closed to further replies.

# contructor what not to do ?

This topic is 5957 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Even I have tried this without any backdraw (for now) I still wondering if it''s safe to do some complicated thing in class constructor: IE: loading a file, assigning device value and so on...
G_Fighter::G_Fighter(LPDIRECT3DDEVICE8 d3dDevice,char * textfile)
{
m_d3dDevice=d3dDevice;
// the text file contain value that will fill the member
// variable of this class

// other member initialisation
}

It seem that someone told me that exception are not handled in a constructor (I do not use them) and also if the init fail I can always assign a "m_ClassReadyToUse=FALSE" any hint ? Dan

##### Share on other sites
Well, I generally use constructors to initalize things that I know before I compile. And I use init functions for stuff that will depend on things in the program.
I typically open files and allocate RAM in init functions too, that way if an object is created just because it is part of a struct it wont take up more ram than it needs.

Jason Mickela
ICQ : 873518
E-Mail: jmickela@sbcglobal.net
------------------------------
"Evil attacks from all sides
but the greatest evil attacks
from within." Me
------------------------------

##### Share on other sites
Exceptions should be thrown in the constructor if the object cannot be constructed. This is one of the main purposes of exceptions. If the ctor throws an exception, assuming "new" has not been overridden (this is its default behavior), the compiler will free the memory allocated to the object and rethrow the inner exception so that it may be caught outside.

This is why you must be careful when constructing objects on the stack that can throw exceptions in their constructors. Notice I said you must be careful, not that it is dangerous. Since care must be taken, some people say avoid throwing in the ctor altogether. I disagree, because it robs you of the ability to use the "construction is initialization" paradigm, which is extremely beneficial IMHO.

The thing you should not do is throw in the destructor. There is no sane way to catch this for stack objects.

##### Share on other sites
I'm on the otherside of the fence from Stoffel, I think ctor's should not be used for initialization. It makes them harder to use in programs and inherit from, because you have no choice when the initialization occurs.

It's not entirely bad to have a constructor that can do initialization, but make sure you have a default constructor as well.

fstream is a good example, you can open the file at construction or later with a call to open. If you could only open files during construction you'd have to delete it and new another one just to open another file.

Magmai Kai Holmlor
- Not For Rent

If it can fail, I don't put it in a ctor.

Edited by - Magmai Kai Holmlor on November 1, 2001 10:18:10 PM

##### Share on other sites
I will then use as anybody some "Init" or "Create" routine after the contructor.

Dan