We use cookies to ensure you have the best browsing experience on our website. Please read our cookie policy for more information about how we use cookies.
For those that are confused, they try to explain it in the overview of the problem. "Note: If you use the nextLine() method immediately following the nextInt() method, recall that nextInt() reads integer tokens; because of this, the last newline character for that line of integer input is still queued in the input buffer and the next nextLine() will be reading the remainder of the integer line (which is empty)."
However, it didn't click for me so...I asked ChatGPT "what gives??" ...and still didn't understand. Then I did my own research and discovered that, when using Scanner function scan.nextInt(); or any other function that scans for numbers, like scan.nextDouble(); in this case, the scanner ignores text. That seemed obvious, but then combine that with the fac that, with stdin (Java Standard Input Library), there is text in the input that acts as a line separator, let's refer to this as /r/n for the sake of clarity (at the bottom of this comment, I’ve linked to a Princeton article with more specifics regarding line separators).
So, if you scan a line of input for numbers, the text of the line separator /r/n remains sitting in the unscanned input ("input buffer"). You can scan as many numbers as you want after that, because they're ignoring Strings. But, as soon as you try to scan a line of Strings...it picks up the leftover /r/n's sitting in a line (I assume they're on a single line) and returns nothing, because /r/n in stdout (Java Standard Output Library) = blank line. This is why you need a dummy scan.nextLine(); that you neither declare as a variable nor use again: it’s there just to scan the line separator text (all the leftover /r/n/r/n/r/n of any numbers you scanned before) before trying to scan for a String Line.
As an analogy, think of the Scanner as PacMan, but you tell PacMan exactly what to eat (and spit back to you...sorry, bad analogy) BUT when it eats numbers, it can't eat text and leaves a line of /r/ns trailing behind every time it eats a number. To get it to eat text, you have to tell it to eat the /r/ns first. When it hears the command scan.nextLine() it will eat the /r/ns and be ready to read more lines of text.
Java Stdin and Stdout II
You are viewing a single comment's thread. Return to all comments →
For those that are confused, they try to explain it in the overview of the problem. "Note: If you use the nextLine() method immediately following the nextInt() method, recall that nextInt() reads integer tokens; because of this, the last newline character for that line of integer input is still queued in the input buffer and the next nextLine() will be reading the remainder of the integer line (which is empty)."
However, it didn't click for me so...I asked ChatGPT "what gives??" ...and still didn't understand. Then I did my own research and discovered that, when using Scanner function
scan.nextInt();
or any other function that scans for numbers, likescan.nextDouble();
in this case, the scanner ignores text. That seemed obvious, but then combine that with the fac that, with stdin (Java Standard Input Library), there is text in the input that acts as a line separator, let's refer to this as/r/n
for the sake of clarity (at the bottom of this comment, I’ve linked to a Princeton article with more specifics regarding line separators).So, if you scan a line of input for numbers, the text of the line separator
/r/n
remains sitting in the unscanned input ("input buffer"). You can scan as many numbers as you want after that, because they're ignoring Strings. But, as soon as you try to scan a line of Strings...it picks up the leftover/r/n
's sitting in a line (I assume they're on a single line) and returns nothing, because/r/n
in stdout (Java Standard Output Library) = blank line. This is why you need a dummyscan.nextLine();
that you neither declare as a variable nor use again: it’s there just to scan the line separator text (all the leftover/r/n/r/n/r/n
of any numbers you scanned before) before trying to scan for a String Line.As an analogy, think of the Scanner as PacMan, but you tell PacMan exactly what to eat (and spit back to you...sorry, bad analogy) BUT when it eats numbers, it can't eat text and leaves a line of
/r/n
s trailing behind every time it eats a number. To get it to eat text, you have to tell it to eat the/r/n
s first. When it hears the commandscan.nextLine()
it will eat the/r/n
s and be ready to read more lines of text.I hope that helps! https://introcs.cs.princeton.edu/java/stdlib/StdIn.java.html#:~:text=A%20%3Cem%3Eline%20separator%3C/em%3E%20is%20defined%20to%20be%20one%20of%20the%20following%20strings%3A%0A%20%20%20%7B%40code%20%5Cn%7D%20(Linux)%2C%20%7B%40code%20%5Cr%7D%20(old%20Macintosh)%2C%0A%20%20%20%7B%40code%20%5Cr%5Cn%7D%20(Windows)%2C%0A%20*%20%20%7B%40code%20%5C%7D%7B%40code%20u2028%7D%2C%20%7B%40code%20%5C%7D%7B%40code%20u2029%7D%2C%20or%20%7B%40code%20%5C%7D%7B%40code%20u0085%7D.%0A%20*%20%20%3Cp%3E