I am trying to read a file and print it's content character by character until the end. To do that I am using the following snippet,
"input.txt" file contains "12345" no carriage return or line feed at the end. The method does print all the characters from the file, but at the end it keeps on printing unknown characters - like the following.
The read() method returns an int, which you cast to a char and then cast back to an int so you can compare it to -1. So your -1 is getting changed to something else in that process. I would recommend moving the cast to char somewhere else, so it doesn't mess up your end-of-file testing.
Paul is correct; the problem is that chars are unsigned so they never support the value −1.
Why are you using the read() method? Unless it is to find out how bad that method is, you should avoid read() (and write()). Wrap that reader in a buffered reader and read the whole line. Or (probably easier) use a Scanner. ReadAllAboutIt (as the people who stood in the middle of the road selling newspapers said when I was little) in the Java™ Tutorials.
Thanks guys. That's was the problem. The solved code,
I am trying write a lexical analyzer, and I need to read from the input file character by character to see what token is it. That's why I want to avoid reading line. I can of course read lines and parse it character by character...
But what's wrong with read() and write()? Should I both avoid the them from both byte/character class?
posted 2 years ago
How are the successive tokens delimited? For a parser, are you parsing code? Do you allow constructs like
or do you require the tokens be spaced apart: x + y? You would find it awkward to read x+y as three tokens with a Scanner.
I think you would do better to read a whole line and scan the line because a buffered reader/Scanner takes only slightly longer to read a whole line than read() does to read one letter.You would have identifyWord() methods and identifyNumber(), identifyOperator(), etc etc.
Campbell Ritchie wrote:That depends on there being a token delimiter. If x+y and x + y are indistinguishable, then it would be very awkward to split on a delimiter.
True. As it is, it would also rely on the file contents being correct.
It seems to me that File-to-Stream functions are still a bit thin on the ground. Maybe we'll get some more with v9.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
posted 2 years ago
Winston Gutkowski wrote:. . . As it is, it would also rely on the file contents being correct. . . .
At least if you parse a file's contents you can check them for correctness. It is much harder to check the other files people read from.
I think the Stream methods didn't take parsing and lexing into consideration because those are specialised techniques. Also there are libraries like JFlex already available.
Seriously? That's what you're going with? I prefer this tiny ad:
Programmatically Create PDF Using Free Spire.PDF with Java