Find out the strange Bug: how to save the data and find out the bug

Find out the strange Bug: how to save the data and find out the bug

Design courses with students. A large program, a small project in the course, practice the decomposition action, once together, it is inevitable to mess up the inch. In fact, this is the way we work. (Video link for course design guidance (36th class hours, 3.18 Banking System Development). The course homepage is at the link. For more information about the guidance document, see the link for the sample program ).
In other words, two people who work in the banking system already said to me, "the file cannot contain data. When the program exits, it is clearly written into, but the result is an empty file ." This is not a small blow.
Software and Bug search, some of which are like playing in the air, so that people will ignore you for half a day. People who want to learn computer science are doing this. They need to learn how to create their own clues and find out the problem.
In other words, the framework of the program for the two students involved is roughly as follows:

Int main () {Bank B; // create a Bank object if (pass () // use pass to verify the user {Bank B; B. work (); // complete various businesses} return 0;} class Bank {......} Bank: Bank () {ifstream infile ("account. dat", ios: in); if (! Infile) {cerr <"open error! "<Endl; exit (1) ;}// the following code reads the previous business data from the file into the Bank object infile. close ();} Bank ::~ Bank () {ofstream outfile ("account. dat", ios: out); if (! Outfile) // test whether the file opening operation is successful. If the operation fails, the system prompts and exits. {Cerr <"open error! "<Endl; exit (1) ;}// the following code writes the business data in the bank object to the file outfile. close (); delete p ;}

Because data needs to be stored in files, an optional solution is to read files in the constructor and write files in the destructor. The above program was designed according to this idea.
However, after the program exits, the file is empty.
The old man also wondered that the statement for writing a file was quite satisfactory, but it was wrong.
Carefully review the file Opening Method in the Destructor ios: out, which seems to be suspected, but is excluded. In a running system, the ios: out method is not commonly used, because opening this method means that the existing files must be rebuilt, with more ios: app.
However, in the design implemented by freshman students, the simplified solution is to read all the data into the memory, operate on the data in the memory, and finally re-build the file, rewrite all data in the memory.
Hundreds of lines of programs, You can't stare at the problem with your eyes. One-step tracking is not a good solution for such a program if the problem is unclear.
The file write part of The Destructor is the most suspicious. I am in the Destructor ~ The Bank adds a sentence“cout<<"in destructor."<<endl;”. The result shows that at last, the Destructor is executed twice.
Then, add a sentence before return 0; of the main function.“cout<<"end of main"<<endl;”The output information is:

In destructor.
End of main
In destructor.

Let's look at the main function again. The problem lies in the main function: Bank B appears twice: one is the local object B of the main function (the former, row 3rd), and the other is in the scope of action, only object B (the latter, row 6th) in a pair of curly braces of the if statement ).
The initial execution of the program, the file is empty, the former executes the constructor, and B stores the empty business. When the password is successfully verified, the latter is created, and the business information is empty. After B. work (); is executed, the destructor of the latter will be executed, and the business information after the business is saved in the file. The file content will not be empty.
However, when the execution of the program leaves the main function, the local variable B (the former) also needs to be analyzed. At this time, the problem is located, and the Business Information in B is empty, after opening and recreating the file, there is no information to be written, and the file is empty.
Therefore, the solution is to remove two Bank B, regardless of the former or the latter.
After the problem is solved, review. The above problems should not happen, but the design defects also exist here. Write the file name directly in the program, and write it in the constructor and destructor, this means that all objects in this class use the same file (as if every object in the Person class eats in the same bowl, it is terrible for multiple banks to store data in one file ). It is reasonable to adopt a mechanism to use different files for different objects.
Of course, the problem in this article is that two Bank B should not be defined.

Copyright Disclaimer: This article is an original article by the blogger and cannot be reproduced without the permission of the blogger.