a question about "ifstream read from a file"

it works well under xp,
but it read the last line twice under ubuntu,
who can teach me how to correct it?

Can you expand on 'read the last line twice' and how is the file formatted?

i know if there are more blank space, it will read twice under xp
but i'm sure it works well under xp,
i think there are difference between xp and ubuntu.


these are last lines in the file:
it read the last line twice,
so there are two same bars showed in the chart,
the yellow bar is redundant.

just seems like this:

hmmm...not sure.
I would approach this by reading in each line with a getline() and then splitting it into separate numbers, this way you can clean off any spurious spaces or carriage returns.

i find a hint,
if the file was edited manually,
this will happen,under linux

Ascii codes denote the following :

These were introduced to control the head of a printer.
chr(13) = carriage return (move to the start(left) of the line)
chr(10) = Line Feed (move down one line.)


These denote end of file or end of transmission
Chr(26) = Ctrl- Z
Chr(04)= Ctrl -D
These are relics from Very old OS and are now obsolete but can still be found in some files.


Standard windows
file based line separation is denoted by chr(13) +Chr(10)Technically printer speak.

End of file markers are sometimes still present in text files on windows files these will be chr(26) (Ctrl-Z)

Standard Unix line separation use only chr(10) which assumes returning to the left of the page. This is more logical in non printer applications (ie disk / memory files) since you would have to insert many spaces or tabs ino the file to maintain the current x position on a new a line.

End of file markers are sometimes still present in text files .. on unix files these wil be Chr(4) (Ctrl-D)

---------------
Fundamentally your problem is that the IFS object is not detecting the end of file when You want it to. This will be due to extra characters after the final line (these may be any combination of those described above)
EG :

9 7 31 0 158.596 156.936-Chr(10)
9 7 30 0 158.096 155.299-Chr(10)
9 7 29 0 156.354 153.872-Chr(10)-Chr(4)
9 7 29 0 156.354 153.872(redundant line)

in the above example the IFS object will not detect the end of file because of the extra character chr(4)
The IFS object may also be coded in such a way that it will not detect the end of file if a line feed is present on the final line
EG

9 7 31 0 158.596 156.936-Chr(10) -I'm not done yet there is another line
9 7 30 0 158.096 155.299-Chr(10) -I'm not done yet there is another line
9 7 29 0 156.354 153.872-Chr(10) -I'm not done yet there is another line
End of File


Easiest solution(s)
Check your file with a hex editor to find out what the end of your files look like to nail down the exact problem

Ensure you transfer the file (from windows to unix) using the Ascii convention

Strip ALL extraneous chars from the end of the file including the final line feed so your file (in a hex editor) would look like :

9 7 31 0 158.596 156.936-Chr(10)
9 7 30 0 158.096 155.299-Chr(10)
9 7 29 0 156.354 153.872

thank you for your help, it works well now