Check if input is only numbers

[eli m]

In my program i ask for input and then i want it to display a certain message when they enter anything except numbers. How would i do this?

 

[Stefan Ram]

In my program i ask for input and then i want it to display a
certain message when they enter anything except numbers. How
would i do this?

I think, recently, someone posted this:

std::string line;
int lineNumber = 0;
while ( std::getline( file, line ) ) {
++ lineNumber;
std::istringstream parser( line );
if ( parser >> i >> j >> k ) { // For example...
// ...
}
}

 

[Bill Gill]

In my program i ask for input and then i want it to display a certain message when they enter anything except numbers. How would i do this?

The way I have been taught is:
int i = 0;
if (!cin >> i)
cout << "error";

Bill

 

[Öö Tiib]

In my program i ask for input and then i want it to display a certain
message when they enter anything except numbers. How would i do this?

Lot of ways

* Check that none of characters that were input is neither less than '0'
nor greater than '9'.
* Use boost lexical_cast.
* Use strtol() and detect how far it got in string.

What have you tried?

 

[Stefan Ram]

In general, parsing textual input is not one of the easiest things to
do in C++.

To parse an input, one first need to know its grammar. Once
the grammar is written, writing a parser is straightforward.

However, when a programmer who is not even capable of
writing the grammar of his input language attempts to write
a parser for it, something is wrong!

There is nothing wrong with not being able to write a
grammar. One just should not attempt to write a parser in
this case. So the blame could be on learners who learn in an
uncoordinated manner or on the teachers who expect them to
write programs reading input without proper preparation.

Even if C++ would provide more support for parsing (for
example, with libraries like YACC or LAX), one still would
need to know the grammar to be used.

 

[Jorgen Grahn]

To parse an input, one first need to know its grammar. Once
the grammar is written, writing a parser is straightforward. ....
Even if C++ would provide more support for parsing (for
example, with libraries like YACC or LAX), one still would
need to know the grammar to be used.

(You mean lex, not LAX, I think.)

Actually C++ /does/ support parsing today, via its regex support.
And you're right of course: the language cannot do your interface
design for you.

/Jorgen

 

[Öö Tiib]

(You mean lex, not LAX, I think.)

Actually C++ /does/ support parsing today, via its regex support.
And you're right of course: the language cannot do your interface
design for you.

The regex comes into play rather soon in well-designed interactive
UI since most modern users can't type anymore. As soon they type
few characters they expect a list of hints.

 

[Öö Tiib]

Regular expressions are best for matching and replacing. They are a rather
poor tool for parsing. You could try to parse some constructs with regular
expressions, but many such constructs become cumbersome, if not even
impossible, to parse with regexes. (Regular expressions have their limits
on what they support. For example, it's not possible to write a regex that
says "a substring with as many '(' characters as ')' characters", which
could be used to parse expressions with nested parentheses.)

Regex is limited and that is good. It is easy to match simple commands
and recognize wildcard characters with it. OP's 'numbers only' are easy
to match with regex ("+[:digit:]" or "+[0-9]").

Regex should not carry parsing scripting or markup language. When parsing
is complex then it is usually most sane to integrate existing script
language (with something like boost:ython or luajit) or existing
markup language (with things like libjson or RapidXML). "Not Invented
Here" guys do not get too far in our industry anymore.

That leaves only odd cases between the two that are difficult with regex
.... yet do not qualify as language or when it is a language without
suitable parsing library. Firing up boost::spirit or YACC/LEX for those
limited cases is not that difficult.

 

[Jorgen Grahn]

Regular expressions are best for matching and replacing. They are a rather
poor tool for parsing.

True, they don't replace e.g. yacc or even lex. But for things like
"Check if input is only numbers" they are useful (or would be, if C++
didn't have strtol(3) and friends already).

/Jorgen

 

[James Kanze]

On 3/9/2013 3:39 PM, eli m wrote:

The way I have been taught is:

int i = 0;
if (!cin >> i)
cout << "error";

Certainly not. That's "(!cin) >> i" in the if, and it shouldn't
even compile.

 

[James Kanze]

Regular expressions are best for matching and replacing. They are a rather
poor tool for parsing. You could try to parse some constructs with regular
expressions, but many such constructs become cumbersome, if not even
impossible, to parse with regexes. (Regular expressions have their limits
on what they support. For example, it's not possible to write a regex that
says "a substring with as many '(' characters as ')' characters", which
could be used to parse expressions with nested parentheses.)

Every parser I've ever written has used regular expressions for
the lexical analysis. That's really what regular expressions
where designed for. For full parsing, of course: regular
expressions can only define a type 3 grammar. For a full
context free grammar (type 2) you'll need more.

If the problem is just to know whether the file contains only
numbers, you don't need more than a type 1 grammar, so regular
expressions are fine.

 

[James Kanze]

True, they don't replace e.g. yacc or even lex.

Lex *is* regular expressions.

 

[Jorgen Grahn]

Lex *is* regular expressions.

It's tokenization driven by regular expressions. I don't think lex is
a replacement for std::regex (or whatever its name is) or the other
way around. (But I haven't used lex for at least a decade.)

/Jorgen