Here are a few questions to help you clarify your understanding of the basics of string handling/usage.
| TRUE✓ | FALSE✗ | Many actions on strings can be done all at once (like input, output, assignment, concatenation, etc.). |
|---|
Although the getline function is great when we want to read a string that contains spacing, it does have a slight drawback. When it is called immediately following a(n) extraction (>>) operation ('immediate' with respect to cin's view of the world, that is), it will input a(n) empty ("") string — hardly what the user wanted to give us. To fix this problem, we must do several things before we call getline.
First we must flush cout. This is because our next action will be to peek cin — and some library implementors fail to have cout print prompts if they aren't 'really' reading input. If we see a newline ('\n') character, we know that we'll fall into the trap outlined above. When this happens, we call cin.ignore() to effectively skip over that character. This should give us a fresh start for our call to getline!
Explain what is wrong (if anything) in each of the following code fragments. (Note: These are fragments! You may assume everything around — most especially before — the fragment is working fine. If anything is wrong, it will be in the lines presented!)
string s;
cout << "Enter string: ";
cin >> s;
s = toupper(s);
cout << "\n\nThat's '" << s << "', right?\n";
The toupper function from cctype is only for char
type data — not strings.
if ("hello" == "Hello")
{
cout << "The world's gone mad!!!\a\n";
}
else
{
cout << "Oh, well, then that's all right, then...\n";
}
Firstly, these two string values will never be equal so
the branch is a waste of code. (One has lower-case h and
the other has upper-case H!)
Secondly, comparison only works for actual string class
objects — not for literal strings! Both of these are
literals and so this comparison won't do what we even want!
(If you put it in a main and try it, you'll find that it
works, but it isn't working correctly. It is comparing the
place in memory where the two literals are stored and reporting
whether they are at the same place or not. We would have liked
it to report if they had the same content or not, of course.)
string s;
char t;
cout << "Enter 'A': ";
cin >> t;
cout << "Enter a line of text: ";
getline(cin, s);
Here we see an example of the situation discussed above in
fill-in-the-blank form. From cin's perspective, an
extraction operation (>>) is immediately followed
by a getline function call. s will always end up
with an empty string value ("").
A common security breech is caused by entering more text than a prompt can handle — known as a buffer-overrun attack. This allows the attacker to corrupt memory in such a way as to gain 'super-user' or 'administrator' access privileges. Is it possible for this to happen with the string class used to read in text? Why/Why not?
Not really. The string class allows its content to
grow as large as the user desires. It can never be overrun.
On the other hand, it can out-grow the memory on the system.
This could lead to the system shutting down entirely —
a.k.a. a DoS or "Denial of Service" attack. But, in order
for this to happen, the attacker would have to enter many
gigabytes of data (more than physical RAM — they'd have
to nearly fill the virtual memory provided by the OS as well)!
It would seem pretty unlikely. (And, this kind of attack
doesn't allow the attacker to gain access. It just shuts down
the machine so no one can benefit from its services.)
When we need to have whole words or lines as data, the string class is great. But when we just need a y/n or single digit/letter menu response, we still use char. Briefly explain why this is so. (There are multiple reasons. Tell all you can muster.)
-- the important data doesn't need so much storage so why waste lots
of memory on a string
-- it is cheaper/more efficient to compare character data than it
is to compare string data
-- ...
What do we do when the user types a word or line when we just wanted a single character from them? Won't the extra characters cause input stream problems later on (such as when we go to read a numeric value)?
We can still allow the user to enter whole words (or even lines) by
using cin's ignore facilities.