Rule of thumb for constructors?

When my program starts up it loads several graphics files, The variables that let me access the loaded files are members of the class sec, should I put the code that loads the files in the constructor for sec, or in a seperate init function, and call that function when the program starts? There will only be one instance of this class, so redundant loading isnt the concern, I just curious which way presents better code?

It's a little unclear what exactly your asking. what environment are your programming in? MFC? Don't know too much about that, Anyways, it doesn't sound like your using classes for the right reason if you had to create an init function for a class; but, if you ask me, go with the constructor. They tend to be more self-contained and less worrisome then Init functions.

I always thought constructors were more for inililizing the members of a class. What im doing is loading external data, the variables that access the data after loaded just happen to be in a class, I was just wondering what was teh proper way to code it?

I would do as you suggest Eber. There is nothing to gain by paying for another function call if you dont have to.

Quote:

---

it doesn't sound like your using classes for the right reason if you had to create an init function for a class; but, if you ask me, go with the constructor. They tend to be more self-contained and less worrisome then Init functions.

---

To the contrary. I think Eber asked the right question. Constructors are for initializing variables. BUT: A constructor has no return value. Therefore, if you do anything that can fail at initialization, use a boolean Init function.

>What im doing is loading external data

Then you basically have two choices. Keep a state and query that like this:

Code:

---

YourClass c( "externat.dat" );

if( c.failed() ) return false;

---

or have an Init function:

Code:

---

YourClass c;

if( ! c.Init("External.dat" ) ) return false;

---

I personally would prefer the Init function, and if you look at bigger suppliers of class libraries that have to load externals, like databases or datafiles, they seem to prefer that, too.

Quote:

---

A constructor has no return value. Therefore, if you do anything that can fail at initialization, use a boolean Init function.

---

That's what exceptions are for:

Code:

---

try {
    YourClass c("externat.dat");
} catch(YourClass::InitFailed) { // or whatever exception system you use
    cerr << "Couldn't initialize YourClass." << endl;
    exit(1);
}

---

Throwing an exception ? For a perfectly legal thing ?
A network path not available, or a file not where you want it to be is nothing exceptional. It's a normal error condition.

Oh, and by the way:

If you need parameters for initialization, that means you will always have to create your objects with new if they are part of a class.