Re: User Input issue
- From: Eric Sosman <Eric.Sosman@xxxxxxx>
- Date: Tue, 02 Oct 2007 15:01:13 -0400
n3o wrote On 10/02/07 13:35,:
Hello Comp.Lang.C Members,
I have an issue with user input that I have been trying to figure out
for the longest. For instance, let's say you have something like this:
void foo()
{
int num;
printf("Please enter a number: ");
scanf("%d", &num); // yes I know this function may throw a
warning with some compilers (MSVC++ 8.0)
...
}
now we know that the int data type uses 4 bytes of memory.
On your machine, perhaps, but not on all.
Let's say
the user enters a number that exceeds the minimum/maximum size the int
data type can hold. This would be considered a bug and would cause the
program to function in an innappropriate manner.
It produces "undefined behavior." That is, the C
language does not specify what scanf() will do if the
input is out of range, and different implementations of
C will behave differently.
To be more specific,
let's say that the programmer wants a real number meaning that they do
not want floating point numbers.
I'm not sure what you mean. If you mean that you
want the user to be able to enter arbitrary real numbers
like pi or e or even phi, you are out of luck: C has no
built-in support for such values.
If that is the case, we know that by
just changing the data type of 'num' to double would not solve the
issue for a specific reason which I will explain in a minute.
You wrote a moment ago that the programmer does not
want floating-point numbers. In C, `double' is a floating-
point number, so why are you even considering it?
Also, by
changing the data type of, 'num,' to long int would not solve the
issue either. Why? long int uses 4 bytes just like int,
Again, this may be true of your machine but is not
true of all.
and double,
which is not what the programmer wants in this instance, uses 8 bytes.
Tru of your machine, but not necessarily of all.
Therefore, if someone could guide me as to how I can fix this minor
problem, I would really appreciate it greatly.
What is the "problem" you want fixed? Adding the
ability to handle arbitrary real numbers is probably
not possible: computers are finite machines and thus
can only deal with a finite number of distinct values.
If the "problem" is to read numbers that are too
large or small for "%d" there may be ways to improve a
bit. But moving the boundaries does not eliminate them;
there will still be numbers too large or too small for
whatever conversion scheme you use, and the behavior of
scanf() when it encounters such numbers will still be
undefined.
But, now that I think
of it, if I make 'num' a double, is it possible to type cast 'num' to
an int data type so that the 'num' will output as a whole number with
no decimal number?
If all you need to do is print the `double' value
rounded to an integer, just leave it as a `double' and
use "%.0f" instead of just "%f".
Also, just as a sidenote, I know that I can use
either a C-style string or C++ string
Not in C, you can't.
and then use the stdlib header
to convert the string to an integer which would solve this little
problem that I have been having with user input, however, I am not
allowed to use such a technique because my Computer Science
programming instructor told me not to use strings since we have not
covered strings yet (I'm a college freshman in a Programming I/Novice
Programming course, although I should be in a higher level CS course
but that's irrelavent at this moment in time.) Therefore, I would like
some guidance as to what functions/implementations I could use that
DOES NOT use strings, that would control the use of oversizing a data-
type; exceeding the maximum/minimum size that a data type can hold.
You could, I suppose, read characters one at a time
with getc() or one of its relatives, and develop the value
of the number as you go. That would avoid the ban on not
using strings, because by handling just one character at
a time, in isolation from others, you would form no strings.
Seems a pretty silly exercise, though.
--
Eric.Sosman@xxxxxxx
.
- Follow-Ups:
- Re: User Input issue
- From: Charlie Gordon
- Re: User Input issue
- References:
- User Input issue
- From: n3o
- User Input issue
- Prev by Date: Re: Should we broaden the topicality of this group?
- Next by Date: Re: data type
- Previous by thread: Re: User Input issue
- Next by thread: Re: User Input issue
- Index(es):
Relevant Pages
|