Quote:
if (charInput != 'N' && charInput != 'n') {

// create file

if (fout.fail()) {
// notify failure
}

else {
// write data
}
}

It would be safer if I did it the other way, since that way, it would override the file only if it is "y" or "Y".

Quote:
P.S. I get the general impression that you are using member variables for things that ought to be more restricted in scope (i.e. locals). This is nearly as bad as using globals for the same purpose. It's confusing because it implies there's a reason for the extra scope when there isn't.

You mean like the var input? I guess I could make them all local. -_-

Quote:
// Do all the file writing here... BTW, you may want to look into better
// techniques for this

This was the only way I knew how to do it. Any suggestions? XD

Looking back, I guess my code is really messy, since this is basically the first project that went over 2000 lines of code. =)

nvm, didn't see the replys.

If you want to know why people say gotos and labels are evil, download the original C source code of the mainframe version of Zork and try to figure out the program logic.

Quote:Original post by WiseElben
It would be safer if I did it the other way, since that way, it would override the file only if it is "y" or "Y".

Good call. :)

Quote:
You mean like the var input? I guess I could make them all local. -_-

Yeah. Member variables basically are intended to allow for communication between methods, and represent the persistent "state of the object". Where no such communication is necessary, the Prinicple of Least Priviledge demands that we not make it available, because
(a) we might make use of it accidentally, or with unexpected side effects:

class LoopProcessor {  int i;  // ...  void foo() {    for (i = 0; i < 10; i++) {      wibble();      bar();    }  }  void bar() {    for (i = 0; i < 5; i++) {      cout "Oops, foo is an infinite loop now" << endl;    }  }}

b) It becomes harder to prove things about our code, because we have to check in more places to determine how and where the variable is being used. That slows down refactoring.

Quote:
This was the only way I knew how to do it. Any suggestions? XD

[google] serialization. "Serialize yourself" is a perfectly reasonable bit of behaviour to implement as an object method. Instead of asking the Hero to expose all the raw bits of information, you should make him do the work. One option for this is to make ostream::operator<< a friend of your class, and then overload it. Another is to provide a method like "std::string Hero::toString()". Also, ICBW about this, but I think you can overload operator()(ostream&), and it will work with operator<< without needing the "friendliness" of ostream. (That is, the stream will respond to the request "output this thing, which is of type 'can be called on an ostream'", by in turn asking the thing "execute using me".) If not, there is almost certainly a way to create that behaviour for the general case, and tuck it away in a library. (Heck, maybe it's in Boost or Loki or something, I dunno :) )

Quote:Looking back, I guess my code is really messy, since this is basically the first project that went over 2000 lines of code. =)

Good stuff. Now is a good time to start learning what you can about cleaning code up, and see how much shorter it becomes once you apply what you've learned. :)