Thread: Using cin with 8-bit integers?

So, for an assignment in Alex Allain's Jumping Into C++, I was supposed to make a high scores program. It works just fine, except it doesn't work with 8-bit integers (or int8_t, as the compiler refers to it). When I entered -5, for some reason, cin puts the value 45 in the 8-bit int var. I can simply assign it -5, so it's definitely not some overflow issue. I'd very much appreciate help with this

Please post your code illustrating the problem, I doubt the problem is actually with your cin line.

Jim

int8_t is an alias to signed char (or possibly just char). So you are asking cin to extract a character. It reads the dash (negative sign) and stores that character in the int8_t. It's ascii/utf8 value is 45.

The only way I can think of to fix it is to read the value initially into an int (or at least a short) and then copy it to the int8_t. And when printing out the int8_t with cout, cast it to an int.

Code:

#include <iostream>
#include <cstdint>

int main() {
    std::int8_t n;
    int x;
    std::cin >> x;
    n = x;
    std::cout << int(n) << '\n';
}

My code is:

Code:

int8_t num;
cin >> num;
cout << num + 0;

Originally Posted by algorism

The only way I can think of to fix it is to read the value initially into an int (or at least a short) and then copy it to the int8_t. And when printing out the int8_t with cout, cast it to an int.

[/code]

In that case, what would be the point of using 8-bit ints instead of regular ones, if I just have to cast to the larger data type?

Originally Posted by MacNilly

If you are asking cin to only read integers that will fit into an 8-bit field, I am afraid you are asking too much of cin. Also, the code above demonstrates a loss of precision error, when assigning to variable n (an 8 bit field) a value that is of type int (32 bit, maybe 64)... its gonna lose some precision in some cases, depending on the value of x. Not only might it lose precision but it might lose a lot of accuracy as well. Basically there's no equality of the value of n to x here at all... then one wonders why do any of this at all and just read a byte, or an int.

What I wanted cin to do was read values into 8-bit ints just like it would for a regular int; if I entered 45, the var gets 45. If I entered something out of the variable's range (like 500 for an 8-bit int, or 1000000000 for a regular int), it wraps around.

Also, I thought I should mention that couting the 8-bit int works when I initialize it to a value I want, like so:

Code:

int8_t num = 50;
cout << num + 0; //needs the +0 so some character isnt couted instead

Though, that doesn't quite address my problem for when I need to read a value from a user instead of set a value I want.

You would be better off using ints.

To cin an 8 bit int is actually a character. The reason your num+0 works is because you are actually printing a temporary int.
You code is functionally equivalent to

Code:

int8_t num = 50;
int temp = num;
cout << temp;

C++ is a typesafe language. Although a char is in effect an 8 bit int, to the iostreams library classes it is a character. Why the insistence on using an 8 bit int? You simply can't do what you want. You can't read an int into a char. And you can't print a char as an int without promotion (which is what your +0 does).

Oh, I see. The reason I insisted on using an 8-bit int is based on the advice about using datatypes no bigger than you'd need. I know that today's computers are powerful enough to, for the most part, not require me to use such tiny data types. Still, I'd like to make this minimalistic type usage a habit, as a small step to becoming good at optimizing code.

But if what you said is true and that I can't have the iostream library read in 8-bit ints like actual numbers, then I might as well move onto another thing. xD

Oh, and I already completed the highscores program soon after the original post, using regular ints in the meantime.

Originally Posted by Tesp

The reason I insisted on using an 8-bit int is based on the advice about using datatypes no bigger than you'd need.

I've never heard that "advice" before.
What's your source on that?

What I wanted cin to do was read values into 8-bit ints just like it would for a regular int; if I entered 45, the var gets 45. If I entered something out of the variable's range (like 500 for an 8-bit int, or 1000000000 for a regular int), it wraps around.

No, overflowing signed integers produces Undefined Behavior.

I know that today's computers are powerful enough to, for the most part, not require me to use such tiny data types. Still, I'd like to make this minimalistic type usage a habit, as a small step to becoming good at optimizing code.

This is called pre-optimization, IMO. An int is usually the "best choice" for the particular processor since it is usually matched to the register sizes of the processor.

Jim

Originally Posted by Tesp

Oh, I see. The reason I insisted on using an 8-bit int is based on the advice about using datatypes no bigger than you'd need. I know that today's computers are powerful enough to, for the most part, not require me to use such tiny data types. Still, I'd like to make this minimalistic type usage a habit, as a small step to becoming good at optimizing code.

But if what you said is true and that I can't have the iostream library read in 8-bit ints like actual numbers, then I might as well move onto another thing. xD

Oh, and I already completed the highscores program soon after the original post, using regular ints in the meantime.

Well it's half true. As another poster pointed out you can create a class and overload the extraction and insertion operators but it is rather pointless to do this when using ints just makes sense.

You have also been misled that using 8 byte ints leads to more optimised code it actually doesn't at all. Using ints of the same word-size as the computer you are using the executable on gives the best performance because these can be aligned on the word-size boundaries.
Alignment

Originally Posted by Elkvis

You could always create a class called 'byte' and overload istream:perator>>

Hm, perhaps.

Originally Posted by algorism

I've never heard that "advice" before.
What's your source on that?

Alex Allain's Jumping into C++ says something to that effect, on page 58. Quote:

Just know that floating point numbers mean “numbers with decimal places”. But floats have only four bytes of space, so they cannot store as many different values as doubles, which have eight bytes of space.

Back when computers had less memory than they do today, this was a bigger deal, and programmers would often go to great lengths to save a few bytes. Nowadays, you will almost always be better off using a double, but in cases where space is critical (perhaps on low-memory systems like cell phones), you still have the option of using a float.

Originally Posted by jimblumberg

No, overflowing signed integers produces Undefined Behavior.

This is called pre-optimization, IMO. An int is usually the "best choice" for the particular processor since it is usually matched to the register sizes of the processor.

Jim

What do you mean by "undefined behavior"? And this stuff about processors?

Originally Posted by Hobbit

Well it's half true. As another poster pointed out you can create a class and overload the extraction and insertion operators but it is rather pointless to do this when using ints just makes sense.

You have also been misled that using 8 byte ints leads to more optimised code it actually doesn't at all. Using ints of the same word-size as the computer you are using the executable on gives the best performance because these can be aligned on the word-size boundaries.
Alignment

Oh, I see. Didn't know that stuff about how the datatype choices you use affect some low-level data arrangement, which sometimes make bigger datatypes faster.

Does this mean that unless I'm coding for some really old hardware with a word size fitting an 8-bit int, I should just look up my computer's word size and choose based on that?

Alex Allain's Jumping into C++ says something to that effect, on page 58

The quote says exactly the opposite of your point.

What do you mean by "undefined behavior"?

Undefined behavior means anything can happen, from appearing to work properly to crashing your system or worse.

And this stuff about processors?

You're kidding right? If you don't know what a processor is you really really should consider another profession. It just happens to be the heart and sole of your, and everyone else's, computer.

Jim

Soul Jim. Sole is a fish!