Code prints last object twice

[Smartflight]

We have been assigned to make a program for a bank using data file handling, as our project.

I am having some trouble at this point... the last object written in the file is printed twice and I've no clue as to why.

Case for display:

file.open("Records.dat", ios::in | ios::binary);
	if (!file)
		cout<<"\nCan not open file.";

	else
	{
		file.seekg (ios::beg);
		while (!file.eof())
		{
			file.read( (char*) &rec, sizeof (account) );
			rec.display();
		}
	}
file.close();

And my display function for the class:

void display () {
	cout<<"\nAccount number: "<<number;
	cout<<"\nName: "<<holder;
	cout<<"\nAddress: "<<add;
	cout<<"\nPhone number: "<<phno;
	cout<<"\nBalance: "<<bal<<endl;
}

I don't see anything wrong in the display function, so I'm guessing it has something to do with the eof() function. But I still can't rectify it :/
Any bright ideas?

[WaltP]

See This

[Smartflight]

I did not understand any of that except the part that says the eof function returns true after the end of file has been read, not when it is reached.

If that's true, why does the following code work?
Honestly, both sets of code seem to be the same to me in program flow :|

while (file)
{
	file.read( (char*) &rec, sizeof (account) );
	if(!file.eof())
	rec.display();
	else
	break;
}

[WaltP]

I did not understand any of that except the part that says the eof function returns true after the end of file has been read, not when it is reached.

If that's true, why does the following code work?
Honestly, both sets of code seem to be the same to me in program flow :|

That's because you are new and haven't developed the keen Spidey Programming sense yet. It'll come...

Follow the code carefully--
Code #1:

while (!file.eof())
{
    file.read( (char*) &rec, sizeof (account) );
    rec.display();
}

A) Test if EOF
B) If not, read the file
C) Process the data

Code #2:

while (file)
{
	file.read( (char*) &rec, sizeof (account) );
	if(!file.eof())
	rec.display();
	else
	break;
}

A) Loop as long as there is no error
B) Read the file
C) Test for EOF
D) If no EOF, process data.

Note the order of the READ and TEST...
Noticing these types of differences is key to programming. And writing out what's actually going on, as I did here, is a major tool to understanding the proper logic.

Just remember, the hard part is writing the sequence of events exactly as they happen rather than writing the sequence of events as you wanted them to happen. You have to be very careful about that. What happens for me as I write the actual sequence, when I get to the error it's not always apparent -- consciously -- but something in the back of the brain whispers "huh?". If you pause a nano-second in confusion, even if that confusion is fleeting,
1- mark that place
2- write a couple more lines
3- then look carefully at that area
Your pencil and paper is your greatest debugging tool at this point. Run through the code writing values down and see what's happening. Then BANG! it hits you!!!

[deceptikon]

That's because you are new and haven't developed the keen Spidey Programming sense yet. It'll come...

How long does that take? Because I've been programming for well over 10 years and still have a dull Spidey sense. :D

[WaltP]

Some people it's inherent. Other can never understand it. You seem to be somewhere between and haven't worked at developing it.

Have you ever done what I just did with any code? If not, you have not been a programmer. A programmer is a detective that searches for reasons why things work and don't work. It looks like you haven't done that yet. Starting now, be much more analytical in all -- that's ALL -- the code you write. Once you get something finished, make a copy and rewrite a small section with a slightly different idea. Then analyze the results. Why did they both work? Why did one work and not the other? Narrow down the difference and keep a journal of the things you find so you can refer back to them and not make the same mistake 5 more times.

Here's an example. Remember that link I gave you? Now here's your working code with a minor change removing unnecessary lines:

while (file)
{
    file.read( (char*) &rec, sizeof (account) );
    if(!file.eof())
    {
        rec.display();
    }
}

We now know why this didn't work:

while (!file.eof())
{
    file.read( (char*) &rec, sizeof (account) );
    rec.display();
}

But why does this work? It still uses .eof() ...

file.read( (char*) &rec, sizeof (account) );
while (!file.eof())
{
    rec.display();
    file.read( (char*) &rec, sizeof (account) );
}

When something doesn't work as expected, don't just muscle through to the answer, changing things and hoping it worked.
1) Completely understand why it didn't work.
2) Figure out (on paper without code) what would fix it.
3) With that info, write the sequence of steps that correctly does the job (on paper)
4) Then translate those steps to code that does the job.
The difference is adding a fix to the code and writing correct code.