Find out the weird bug: How the data can't be stored in

Take the students to do the curriculum design. A large program, the course has done a small project, practiced the decomposition of the action, one to the combined, it is inevitable or disorderly. In fact, the actual combat kungfu, this is the way out. (Course Design Guide video link (36th class, 3.18 banking system development), course homepage in link, instruction document See link, sample program see link).
In other words, there are two students who do the banking system and I said, "The file is not written in the data." Program quit, obviously written in, the result is an empty file. "It's not a small blow.
Do software, look for bugs, some like playing air, so that half a day, people will ignore you. The person who learns the computer, practice is this kind of kungfu, must learn oneself to create the clue, find out the problem lies.
Say, the problem of the two students of the program, the framework is broadly as follows:

intMain () {Bank B;//Create a Bank object    if(Pass ())//Pass User verification{Bank B; B.work ();//completion of various business}return 0;}classBank{...} Bank::bank () {Ifstream infile ("Account.dat", ios::in);if(!infile) {Cerr<<"Open error!"<<endl;Exit(1); }//The following code reads the business data from the file into the Bank objectInfile.close ();} Bank::~bank () {ofstream outfile ("Account.dat", ios::out);if(!outfile)//test whether the file open operation is successful or unsuccessful, then exit after the prompt. {Cerr<<"Open error!"<<endl;Exit(1); }//The following code, writes business data from the Bank object to the fileOutfile.close ();DeleteP;}

Because the data is to be stored in the file, the alternative is to read the file in the constructor and write the file in the destructor. The above procedure is designed according to this idea.
However, after the program exits, the file is empty.
Lao He looked also puzzled, write the statement of the file, but is not correct.
Carefully review the opening of the file in the destructor Ios::out, seems suspicious, but ruled out. In the actual running system, the ios::out way is not commonly used, because such an open, also means that the existence of files to be rebuilt, with Ios::app more.
However, in this design, implemented by a freshman, the simplified solution is to read all the data into memory, manipulate the data in memory, and finally, rebuild the file to rewrite all the data in memory.
Hundreds of lines of the program, you can not stare at the problem with the eyes. Single-step tracking, for such programs, if the problem is not clear where the specific, is not a good way.
The part of the destructor that writes the file is most suspicious. I added a sentence in the destructor ~bank “cout<<"in destructor."<<endl;” . The result shows that, finally, the destructor executes two times.
Then, in the return 0 of the main function, add a sentence before the “cout<<"end of main"<<endl;” output information is:

In destructor.
End of Main
In destructor.

Look at the main function again, the truth. The problem is in the main function: Bank B appears two times: One is a local object B (the former, the 3rd line) that belongs to the main function, and the other is scoped to object B (the latter, line 6th) within a pair of curly braces of the IF statement.
The first time the program executes, the file is empty, the former executes the constructor, and B saves the empty business. When the user password is validated successfully, the latter is created and the natural business information is also empty. When the B.work () is executed, the latter's destructor is executed, and the business information after this operation is saved in the file. The file content will not be empty.
However, when the execution of the program leaves the main function, its local variable B (the former) also to be analyzed, this is where the problem is, the business information in this B is empty, the file opened after rebuilding, there is no information to write, and finally the empty file.
So, the solution would be two bank B, whichever the former or the latter, remove one.
Solve the problem, and then reflect on it. The aforementioned problems naturally should not occur, but the defects of design here also exist. Writing the file name directly in the program, and writing it in constructors and destructors, means that all objects of the class use the same file (as every object in the person class eats with the same bowl, and many banks have data in one file, which is horrible). It is reasonable to take some kind of mechanism, different objects, to use different files.
Of course, for the problem in this article, it is not a definition of two Bank B.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Find out the weird bug: How the data can't be stored in