Thanks for taking the time to read this first of all,
I'm currently writing a driver program for a class in C++ and I need some input from the user. I've started using typedef to create validation programs so I can switch between different types fairly easily. For the particular problem I'm working on, I've found that I'm only working with char which leads me to my questions:
My validation checks to see if the input is char. Is using validation pointless if I know I'm just working with char in particular? Everything that the user types in seems to be a char.
Is there anything that the user could type in that won't be considered a char?
This question may seem a bit trivial but I've never really thought about this before! Still learning the language, so any guidance is appreciated.
Code in question (ElementType is of type char):
void getInput( ElementType & cho )
{
while ( !(cin >> cho) )
{
cout<< "That is an invalid input..."
<< "\nTry again: ";
}
cout<< endl;
}
Is there anything that the user could type in that won't be considered a char?
Yes: Shift, Ctrl, Alt, Num Lock to name a few.
The point is that a keyboard is its own beast with a potential output for each key-press, key-release of every key. A keyboard driver (software) takes these events and translates them into a series of char for a program's cin/stdin. Alternatively, a program could get access to the low level events, but may be beyond standard C++ code.
Recommend staying with the model that cin receives sporadically any of the usually 256 different char including '\0' until program-end or cin is closed from some source be it a keyboard, re-directed file input, piped input, or a remote device. Ignore that idea that input usually comes from a keyboard. It is simply a sequence of char.
Is using validation pointless?
Validation is useful. Code should validate the char arriving per the requirements of the program - not the requirements of char. Example, code may have trouble handing a null character, a negative char, a char outside the ASCII range of 0 - 127, or too many char between line endings. Validating input makes code resilient against hackers who will exploit a vulnerable program.
Under Linux, with UTF-8 input, I can certainly type a lot of stuff that isn't a char. E.g. typing รก gives two bytes. There are quite a lot of others, directly typeable depending on the keyboard handling in place.
International character handling is complex. Not all the world types ASCII.
Related
I have GLFW key_callback() and I'm trying to detect if an alphabetic character is pressed. I use this function isalpha(). I've noticed that some keys such as Shift and Alt are treated as alphabetic characters if I perform the following code:
#include <iostream>
int main()
{
// 340: printed int if the Shift key is pressed.
if( isalpha(340) )
std::cout << "alpha" << std::endl;
else
std::cout << "not alpha" << std::endl;
return 0;
}
The preceding code yields alpha. I can validate the range of integers that are passed to the function but this makes no sense since I'm not taking advantage of the function. My question is is it safe to pass any integer to that function and use simple if-statement to validate alphabetic characters? What is the precaution need to be taken if any in case using this function?
key_callback is not a standard part of C++, so I searched and assume that the one you're talking about is part of the GLFW library. In that library, the key_callback gives a keyboard scancode.
Scancodes are not characters. In a typical input model, there's a state machine that maps scancodes (and sequences and combinations of scancodes) to characters. This is the layer that would allow you to change your QWERTY keyboard to work like a Dvorak keyboard or like one designed for typing in another language. This key_callback is lower level, and leaves the mapping to you.
The C++ std::isalpha function takes a char cast to an int or a special sentinel value EOF, which is typically -1. (On some systems, you'll find that you need to first cast your char to an unsigned char before converting it to an int.) Scancodes are not chars, so passing a scancode to std::isalpha is meaningless.
In particular, the value 340 is outside the range of an unsigned char, and it's not EOF, so it really can't be expected to do anything sensible.
If you need chars, you will have to build your own mapping from scancodes (and combinations of scancodes) to chars. It looks like that library has constants defined for the scancodes. For example, GLFW_KEY_LEFT_SHIFT is 340. That should help. If you just need to know if a particular key is pressed or released, you can compare the scancodes to the appropriate constants.
Note: You tagged the question C++, but you linked to the documentation for the C version of isalpha.
Just to summarize the wisdom from the discussion in the comments into a short answer.
Your code has undefined behaviour (UB), for reasons discussed in the comments.
Therefore, the outcome is unpredictable and most likely incorrect.
Code with with UB should be avoided as much as possible.
It's not clear what you mean by safe. It's unlikely that it will immediately lead to disaster, but UB in some important code (such as a program controlling an airplane) can do.
The title is misleading because I'm more interested in finding an alternate solution. My gut feeling is that checking whether the buffer is empty is not the most ideal solution (at least in my case).
I'm new to C++ and have been following Bjarne Stroustrup's Programming Principles and Practices using C++. I'm currently on Chapter 7, where we are "refining" the calculator from Chapter 6. (I'll put the links for the source code at the end of the question.)
Basically, the calculator can take multiple inputs from the user, delimited by semi-colons.
> 5+2; 10*2; 5-1;
= 7
> = 20
> = 4
>
But I'd like to get rid of the prompt character ('>') for the last two answers, and display it again only when the user input is asked for. My first instinct was to find a way to check if the buffer is empty, and if so, cout the character and if not, proceed with couting the answer. But after a bit of googling I realized the task is not as easy as I initially thought... And also that maybe that wasn't a good idea to begin with.
I guess essentially my question is how to get rid of the '>' characters for the last two answers when there are multiple inputs. But if checking the cin buffer is possible and is not a bad idea after all, I'd love to know how to do it.
Source code: https://gist.github.com/Spicy-Pumpkin/4187856492ccca1a24eaa741d7417675
Header file: http://www.stroustrup.com/Programming/PPP2code/std_lib_facilities.h
^ You need this header file. I assume it is written by the author himself.
Edit: I did look around the web for some solutions, but to be honest none of them made any sense to me. It's been like 4 days since I picked up C++ and I have a very thin background in programming, so sometimes even googling is a little tough..
As you've discovered, this is a deceptively complicated task. This is because there are multiple issues here at play, both the C++ library, and the actual underlying file.
C++ library
std::cin, and C++ input streams, use an intermediate buffer, a std::streambuf. Input from the underlying file, or an interactive terminal, is not read character by character, but rather in moderately sized chunks, where possible. Let's say:
int n;
std::cin >> n;
Let's say that when this is done and over is, n contains the number 42. Well, what actually happened is that std::cin, more than likely, did not read just two characters, '4' and '2', but whatever additional characters, beyond that, were available on the std::cin stream. The remaining characters were stored in the std::streambuf, and the next input operation will read them, before actually reading the underlying file.
And it is equally likely that the above >> did not actually read anything from the file, but rather fetched the '4' and the '2' characters from the std::streambuf, that were left there after the previous input operation.
It is possible to examine the underlying std::streambuf, and determine whether there's anything unread there. But this doesn't really help you.
If you were about to execute the above >> operator, you looked at the underlying std::streambuf, and discover that it contains a single character '4', that also doesn't tell you much. You need to know what the next character is in std::cin. It could be a space or a newline, in which case all you'll get from the >> operator is 4. Or, the next character could be '2', in which case >> will swallow at least '42', and possibly more digits.
You can certainly implement all this logic yourself, look at the underlying std::streambuf, and determine whether it will satisfy your upcoming input operation. Congratulations: you've just reinvented the >> operator. You might as well just parse the input, a character at a time, yourself.
The underlying file
You determined that std::cin does not have sufficient input to satisfy your next input operation. Now, you need to know whether or not input is available on std::cin.
This now becomes an operating system-specific subject matter. This is no longer covered by the standard C++ library.
Conclusion
This is doable, but in all practical situations, the best solution here is to use an operating system-specific approach, instead of C++ input streams, and read and buffer your input yourself. On Linux, for example, the classical approach is to set fd 0 to non-blocking mode, so that read() does not block, and to determine whether or not there's available input, just try read() it. If you did read something, put it into a buffer that you can look at later. Once you've consumed all previously-read buffered input, and you truly need to wait for more input to be read, poll() the file descriptor, until it's there.
Suppose I created a character array say of 20 bytes and prompts the use to input their name provided their name should not be more than 20 characters...
For Example:
char Name[20];
gets(Name);
Now suppose his name is abcdefghijklmnopqrstuvwxyz
But as soon as he enters abcdefghijklmnopqrst, the Name should not take any further input... Neither the further input provided by the user should appear on the console screen... Only the cursor should blink until he presses enter. So how to do it??
More Information
Operating System: Windows 7
Compiler: Visual C++ 2010 Express
The manpage states:
Never use gets(). Because it is impossible to tell without knowing the data in advance how many characters gets() will read, and because gets() will continue to store characters past the end of the buffer, it is extremely dangerous to use. It has been used to break computer security. Use fgets() instead.
So you could use fgets:
char *fgets(char *s, int size, FILE *stream);
Yet the input sequence doesn't stop yet; however, you are no longer running into undefined behaviour and security holes, iff used correctly.
You should better use C++ facilities like std::string, std::getline, and the standard iostreams. They won't enable you stopping input, however, they prevent security holes when used in the canonical manner.
Summary of Standard Alternatives:
gets() can not be used correctly. People will may die when you use this (you wouldn't find a smile on my face as I am not kidding). There is provably no correct way to use it. Do not forget it, but throw it out of your toolbox now.
fgets() can be used correctly, but there's a lot of opportunity to misuse it.
iostreams and strings are automatically used correctly. Use them.
Unforunately, there is no builtin solution to read at max N characters from input without having to discard superfluous characters typed in. You would have to use a 3rd-party library or roll your own.
Here's silly answer:
If you want for example the user to enter a name with maximum 20 characters
Create a char array with. size[20]
Ask the user to enter the size of the name and check the validity of the number if its less than or equal.20 then move on and add the name else ask the user to enter the size again.
You can use a string instead of a char but that won't make sure that the user actually followed the size rule
For example a user can enter a size 10 and the program will allow him to enter the name but once he's allowed if you are using the.string he can write as many as he wishes.
OR using a char array. for name with 20 or less.characters
For example the code would need a simple for loop
Since we already have the size given which is less than or equal.20
For(int i =0; i<20; i++)
Cin>>char[i]
Then you can assign the characters into a string.
So this is a problem that I've been having since I started programming (Not that long ago. I still don't know why I started with C++). When I have some integer variables and the user's input defines them, if the user inputs something other than an integer the program freaks out and runs an endless loop of the last command it was given. I don't think sample code is needed but if it is I can make a basic example pretty easily.
If you want to know exactly what your mistake was, then we'd need to see your code, but the usual idiom is like this:
int i;
while (std::cin >> i) {
// do something with the user's input, i
}
if (std::cin.fail()) {
std::cout << "not a number!\n";
}
If failure occurs and you want to get past the invalid input so that the user can try again, first call cin.clear(), then either cin.ignore(std::numeric_limits<std::streamsize>::max(), '\n') to ignore the whole line, or std::string s; std::cin >> s; to ignore a whitespace-separated word.
Beware that because the second case actually constructs the string in memory, the user could input a few gigabytes without a space, and the program will fail. That's usually fine if the input is from a terminal, it's the user's own stupid fault. It might be less fine if the input is from an HTTP request or other untrusted source, so some time in future you might end up worrying about it...
Check this out Guess the number - Infinite loop when bad read
When programming always, and i mean always, validate your input.
Check if the input you get is sane.
What i mean by that if you get something that is supposed to be int check if it is.
Convert it if it is not.
If you get a string check if it is in bounds, meaning is it to long, to short, to whatever.
cin
Would be the Term to Google for in your case.
My brother recently started learning C++. He told me a problem he encountered while trying to validate input in a simple program. He had a text menu where the user entered an integer choice, if they entered an invalid choice, they would be asked to enter it again (do while loop). However, if the user entered a string instead of an int, the code would break.
I read various questions on stackoverflow and told him to rewrite his code along the lines of:
#include<iostream>
using namespace std;
int main()
{
int a;
do
{
cout<<"\nEnter a number:"
cin>>a;
if(cin.fail())
{
//Clear the fail state.
cin.clear();
//Ignore the rest of the wrong user input, till the end of the line.
cin.ignore(std::numeric_limits<std::streamsize>::max(),\
'\n');
}
}while(true);
return 0;
}
While this worked ok, I also tried a few other ideas:
1. Using a try catch block. It didn't work. I think this is because an exception is not raised due to bad input.
2. I tried if(! cin){//Do Something} which didn't work either. I haven't yet figured this one out.
3. Thirdly, I tried inputting a fixed length string and then parsing it. I would use atoi(). Is this standards compliant and portable? Should I write my own parsing function?
4. If write a class that uses cin, but dynamically does this kind of error detection, perhaps by determining the type of the input variable at runtime, would it have too much overhead? Is it even possible?
I would like to know what is the best way to do this kind of checking, what are the best practices?
I would like to add that while I am not new to writing C++ code, I am new to writing good standards compliant code. I am trying to unlearn bad practices and learn the right ones. I would be much obliged if answerers give a detailed explanation.
EDIT: I see that litb has answered one of my previous edits. I'll post that code here for reference.
#include<iostream>
using namespace std;
int main()
{
int a;
bool inputCompletionFlag = true;
do
{
cout<<"\nEnter a number:"
cin>>a;
if(cin.fail())
{
//Clear the fail state.
cin.clear();
//Ignore the rest of the wrong user input, till the end of the line.
cin.ignore(std::numeric_limits<std::streamsize>::max(),\
'\n');
}
else
{
inputCompletionFlag = false;
}
}while(!inputCompletionFlag);
return 0;
}
This code fails on input like "1asdsdf". I didn't know how to fix it but litb has posted a great answer. :)
Here is code you could use to make sure you also reject things like
42crap
Where non-number characters follow the number. If you read the whole line and then parse it and execute actions appropriately it will possibly require you to change the way your program works. If your program read your number from different places until now, you then have to put one central place that parses one line of input, and decides on the action. But maybe that's a good thing too - so you could increase the readability of the code that way by having things separated: Input - Processing - Output
Anyway, here is how you can reject the number-non-number of above. Read a line into a string, then parse it with a stringstream:
std::string getline() {
std::string str;
std::getline(std::cin, str);
return str;
}
int choice;
std::istringstream iss(getline());
iss >> choice >> std::ws;
if(iss.fail() || !iss.eof()) {
// handle failure
}
It eats all trailing whitespace. When it hits the end-of-file of the stringstream while reading the integer or trailing whitespace, then it sets the eof-bit, and we check that. If it failed to read any integer in the first place, then the fail or bad bit will have been set.
Earlier versions of this answer used std::cin directly - but std::ws won't work well together with std::cin connected to a terminal (it will block instead waiting for the user to input something), so we use a stringstream for reading the integer.
Answering some of your questions:
Question: 1. Using a try catch block. It didn't work. I think this is because an exception is not raised due to bad input.
Answer: Well, you can tell the stream to throw exceptions when you read something. You use the istream::exceptions function, which you tell for which kind of error you want to have an exception thrown:
iss.exceptions(ios_base::failbit);
I did never use it. If you do that on std::cin, you will have to remember to restore the flags for other readers that rely on it not throwing. Finding it way easier to just use the functions fail, bad to ask for the state of the stream.
Question: 2. I tried if(!cin){ //Do Something } which didn't work either. I haven't yet figured this one out.
Answer: That could come from the fact that you gave it something like "42crap". For the stream, that is completely valid input when doing an extraction into an integer.
Question: 3. Thirdly, I tried inputting a fixed length string and then parsing it. I would use atoi(). Is this standards compliant and portable? Should I write my own parsing function?
Answer: atoi is Standard Compliant. But it's not good when you want to check for errors. There is no error checking, done by it as opposed to other functions. If you have a string and want to check whether it contains a number, then do it like in the initial code above.
There are C-like functions that can read directly from a C-string. They exist to allow interaction with old, legacy code and writing fast performing code. One should avoid them in programs because they work rather low-level and require using raw naked pointers. By their very nature, they can't be enhanced to work with user defined types either. Specifically, this talks about the function "strtol" (string-to-long) which is basically atoi with error checking and capability to work with other bases (hex for example).
Question: 4. If I write a class that uses cin, but dynamically do this kind of error detection, perhaps by determining the type of the input variable at runtime, will it have too much overhead? Is it even possible?
Answer: Generally, you don't need to care too much about overhead here (if you mean runtime-overhead). But it depends specifically on where you use that class. That question will be very important if you are writing a high performance system that processes input and needs to have high throughout. But if you need to read input from a terminal or a file, you already see what this comes down to: Waiting for the user to input something takes really so long, you don't need to watch runtime costs at this point anymore on this scale.
If you mean code overhead - well it depends on how the code is implemented. You would need to scan your string that you read - whether it contains a number or not, whether some arbitrary string. Depending on what you want to scan (maybe you have a "date" input, or a "time" input format too. Look into boost.date_time for that), your code can become arbitrarily complex. For simple things like classifying between number or not, I think you can get away with small amount of code.
This is what I do with C but it's probably applicable for C++ as well.
Input everything as a string.
Then, and only then, parse the string into what you need. It's sometimes better to code your own than try to bend someone else's to your will.
In order to get the exceptions with iostreams you need to set the proper exception flag for the stream.
And I would use get_line to get the whole line of input and then handle it accordingly - use lexical_cast, regular expressions (for example Boost Regex or Boost Xpressive, parse it with Boost Spirit, or just use some kind of appropriate logic
What I would do is twofold: First, try to validate the input, and extract the data, using a regular expression, if the input is somewhat not trivial. It can be very helpful also even if the input is just a series of numbers.
Then, I like to use boost::lexical_ cast, that can raise a bad_ lexical_ cast exception if the input cannot be converted.
In your example:
std::string in_str;
cin >> in_str;
// optionally, test if it conforms to a regular expression, in case the input is complex
// Convert to int? this will throw bad_lexical_cast if cannot be converted.
int my_int = boost::lexical_cast<int>(in_str);
Forget about using formatted input (the >> operator) directly in real code. You will always need to read raw text with std::getline or similar and then use your own input parsing routines (which may use of the >> operator) to parse the input.
How about a combination of the various approaches:
Snag the input from std::cin using std::getline(std::cin, strObj) where strObj is a std::string object.
Use boost::lexical_cast to perform a lexical translation from strObj to either a signed or unsigned integer of largest width (e.g., unsigned long long or something similar)
Use boost::numeric_cast to cast the integer down to the expected range.
You could just fetch the input with std::getline and then call boost::lexical_cast to the appropriately narrow integer type as well depending on where you want to catch the error. The three step approach has the benefit of accepting any integer data and then catch narrowing errors separately.
I agree with Pax, the simplest way to do this is to read everything as string, then use TryParse to verify the input. If it is in the right format, then proceed, otherwhise just notify the user and use continue on the loop.
One thing that hasn't been mentioned yet is that it is usually important that you test to see if the cin >> operation worked before using the variable that supposedly got something from the stream.
This example is similar to yours, but makes that test.
#include <iostream>
#include <limits>
using namespace std;
int main()
{
while (true)
{
cout << "Enter a number: " << flush;
int n;
if (cin >> n)
{
// do something with n
cout << "Got " << n << endl;
}
else
{
cout << "Error! Ignoring..." << endl;
cin.clear();
cin.ignore(numeric_limits<streamsize>::max(), '\n');
}
}
return 0;
}
This will use the usual operator >> semantics; it will skip whitespace first, then try to read as many digits as it can and then stop. So "42crap" will give you the 42 then skip over the "crap". If that isn't what you want, then I agree with the previous answers, you should read it into a string and then validate it (perhaps using a regular expression - but that may be overkill for a simple numeric sequence).