Mixing
Weird behaviour when using read_line in a loop
My first program in Rust is supposed to take input from the user in the form of characters, either C or F:
use std::io;
fn main() {
let mut srcunit = String::new();
let mut switch = true;
while switch {
println!("source unit? F or C?");
io::stdin().read_line(&mut srcunit).expect(
"failed to read src unit",
);
if srcunit.trim() == "F" || srcunit.trim() == "C" {
println!("doing things right with {}", srcunit);
switch = false;
} else {
println!("either F or C, not {}", srcunit);
}
}
println!("you pressed {}", srcunit);
}
When I start the program and press either F or C, it works right, so I'm skipping this here. The weird part comes when I press another character. I expect my program to ask again for either F or C until I press one of those characters. When I do, it should leave the while loop and tell me what I've pressed.
source unit? F or C?
G
either F or C, not G //so far so good
source unit? F or C?
F
either F or C, not G //why is F not assigned to the srcunit variable? It's supposed to leave the loop now.
F //why does it print this line? I didn't press a key or have a println function/macro that does this
source unit? F or C?
V
either F or C, not G //it's still G, wtf
F //again, why are those two lines printed? Where does it store, that I pressed F previously?
V
rust
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
add a comment |
My first program in Rust is supposed to take input from the user in the form of characters, either C or F:
use std::io;
fn main() {
let mut srcunit = String::new();
let mut switch = true;
while switch {
println!("source unit? F or C?");
io::stdin().read_line(&mut srcunit).expect(
"failed to read src unit",
);
if srcunit.trim() == "F" || srcunit.trim() == "C" {
println!("doing things right with {}", srcunit);
switch = false;
} else {
println!("either F or C, not {}", srcunit);
}
}
println!("you pressed {}", srcunit);
}
When I start the program and press either F or C, it works right, so I'm skipping this here. The weird part comes when I press another character. I expect my program to ask again for either F or C until I press one of those characters. When I do, it should leave the while loop and tell me what I've pressed.
source unit? F or C?
G
either F or C, not G //so far so good
source unit? F or C?
F
either F or C, not G //why is F not assigned to the srcunit variable? It's supposed to leave the loop now.
F //why does it print this line? I didn't press a key or have a println function/macro that does this
source unit? F or C?
V
either F or C, not G //it's still G, wtf
F //again, why are those two lines printed? Where does it store, that I pressed F previously?
V
rust
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
add a comment |
My first program in Rust is supposed to take input from the user in the form of characters, either C or F:
use std::io;
fn main() {
let mut srcunit = String::new();
let mut switch = true;
while switch {
println!("source unit? F or C?");
io::stdin().read_line(&mut srcunit).expect(
"failed to read src unit",
);
if srcunit.trim() == "F" || srcunit.trim() == "C" {
println!("doing things right with {}", srcunit);
switch = false;
} else {
println!("either F or C, not {}", srcunit);
}
}
println!("you pressed {}", srcunit);
}
When I start the program and press either F or C, it works right, so I'm skipping this here. The weird part comes when I press another character. I expect my program to ask again for either F or C until I press one of those characters. When I do, it should leave the while loop and tell me what I've pressed.
source unit? F or C?
G
either F or C, not G //so far so good
source unit? F or C?
F
either F or C, not G //why is F not assigned to the srcunit variable? It's supposed to leave the loop now.
F //why does it print this line? I didn't press a key or have a println function/macro that does this
source unit? F or C?
V
either F or C, not G //it's still G, wtf
F //again, why are those two lines printed? Where does it store, that I pressed F previously?
V
rust
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
My first program in Rust is supposed to take input from the user in the form of characters, either C or F:
use std::io;
fn main() {
let mut srcunit = String::new();
let mut switch = true;
while switch {
println!("source unit? F or C?");
io::stdin().read_line(&mut srcunit).expect(
"failed to read src unit",
);
if srcunit.trim() == "F" || srcunit.trim() == "C" {
println!("doing things right with {}", srcunit);
switch = false;
} else {
println!("either F or C, not {}", srcunit);
}
}
println!("you pressed {}", srcunit);
}
When I start the program and press either F or C, it works right, so I'm skipping this here. The weird part comes when I press another character. I expect my program to ask again for either F or C until I press one of those characters. When I do, it should leave the while loop and tell me what I've pressed.
source unit? F or C?
G
either F or C, not G //so far so good
source unit? F or C?
F
either F or C, not G //why is F not assigned to the srcunit variable? It's supposed to leave the loop now.
F //why does it print this line? I didn't press a key or have a println function/macro that does this
source unit? F or C?
V
either F or C, not G //it's still G, wtf
F //again, why are those two lines printed? Where does it store, that I pressed F previously?
V
rust
rust
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
edited Jul 21 '17 at 14:26
Shepmaster
152k14297435
152k14297435
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
asked Jul 21 '17 at 8:37
fancyPantsfancyPants
39.2k166581
39.2k166581
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
From the documentation for read_line:
Read all bytes until a newline (the 0xA byte) is reached, and append them to the provided buffer.
(Emphasis mine.) You need to clear the string before reading the next line, for example by calling the clear() method on the string, otherwise the answers are accumulated in the variable.
Alternatively, you can define the variable in the loop (but this is slightly less efficient because this way, String will not be able to reuse the already allocated storage for the next answer, it has to be deallocated and reallocated again).
See also this question, asked recently. Looks like this is a common trap.
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
1
In other words, those extra lines are printed because they're part ofsrcunit.read_linekeeps adding the new data to the end of it.
– Yann Vernier
Jul 21 '17 at 8:47
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f45232943%2fweird-behaviour-when-using-read-line-in-a-loop%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
From the documentation for read_line:
Read all bytes until a newline (the 0xA byte) is reached, and append them to the provided buffer.
(Emphasis mine.) You need to clear the string before reading the next line, for example by calling the clear() method on the string, otherwise the answers are accumulated in the variable.
Alternatively, you can define the variable in the loop (but this is slightly less efficient because this way, String will not be able to reuse the already allocated storage for the next answer, it has to be deallocated and reallocated again).
See also this question, asked recently. Looks like this is a common trap.
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
1
In other words, those extra lines are printed because they're part ofsrcunit.read_linekeeps adding the new data to the end of it.
– Yann Vernier
Jul 21 '17 at 8:47
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
add a comment |
From the documentation for read_line:
Read all bytes until a newline (the 0xA byte) is reached, and append them to the provided buffer.
(Emphasis mine.) You need to clear the string before reading the next line, for example by calling the clear() method on the string, otherwise the answers are accumulated in the variable.
Alternatively, you can define the variable in the loop (but this is slightly less efficient because this way, String will not be able to reuse the already allocated storage for the next answer, it has to be deallocated and reallocated again).
See also this question, asked recently. Looks like this is a common trap.
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
1
In other words, those extra lines are printed because they're part ofsrcunit.read_linekeeps adding the new data to the end of it.
– Yann Vernier
Jul 21 '17 at 8:47
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
add a comment |
From the documentation for read_line:
Read all bytes until a newline (the 0xA byte) is reached, and append them to the provided buffer.
(Emphasis mine.) You need to clear the string before reading the next line, for example by calling the clear() method on the string, otherwise the answers are accumulated in the variable.
Alternatively, you can define the variable in the loop (but this is slightly less efficient because this way, String will not be able to reuse the already allocated storage for the next answer, it has to be deallocated and reallocated again).
See also this question, asked recently. Looks like this is a common trap.
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
From the documentation for read_line:
Read all bytes until a newline (the 0xA byte) is reached, and append them to the provided buffer.
(Emphasis mine.) You need to clear the string before reading the next line, for example by calling the clear() method on the string, otherwise the answers are accumulated in the variable.
Alternatively, you can define the variable in the loop (but this is slightly less efficient because this way, String will not be able to reuse the already allocated storage for the next answer, it has to be deallocated and reallocated again).
See also this question, asked recently. Looks like this is a common trap.
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
edited Nov 20 '18 at 21:36
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
answered Jul 21 '17 at 8:42
Florian WeimerFlorian Weimer
15.6k31145
15.6k31145
1
In other words, those extra lines are printed because they're part ofsrcunit.read_linekeeps adding the new data to the end of it.
– Yann Vernier
Jul 21 '17 at 8:47
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
add a comment |
1
In other words, those extra lines are printed because they're part ofsrcunit.read_linekeeps adding the new data to the end of it.
– Yann Vernier
Jul 21 '17 at 8:47
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
1
1
In other words, those extra lines are printed because they're part of
srcunit. read_line keeps adding the new data to the end of it.– Yann Vernier
Jul 21 '17 at 8:47
In other words, those extra lines are printed because they're part of
srcunit. read_line keeps adding the new data to the end of it.– Yann Vernier
Jul 21 '17 at 8:47
2
2
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
The key example in that example (hope I got the link right) is that the variable is declared in the loop, so it is automatically recreated for each iteration.
– Florian Weimer
Jul 21 '17 at 8:54
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f45232943%2fweird-behaviour-when-using-read-line-in-a-loop%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
