0

I am coding a C++ program to calculate a math problem. I first write:

int x = 1
int y = 1
int z = 1
int answer = x * y * z
cout << answer << endl;

And when I build and run that, it prints 1. But when I do this:

   int x = 1234;
    int y = 5243;
    int z = 1142;
    int answer =  x * y * z;
    cout << answer << endl ;

It prints out instead a answer, which is 7388502404, but a code I don't understand: "-1201352188". Could you explain why does this code happens, and how to solve the code?

Alex11001100
  • 3
  • 2
  • 1
    Typically `int` can only hold numbers up to about 2.2 billion.after you pass that things get... [weird](https://en.cppreference.com/w/cpp/language/ub). – user4581301 Jun 28 '20 at 04:16
  • In this case you get 7,388,582,404, too big. But if you look at that as a hexadecimal number you get 1 B8 64 D2 04. The usual behaviour is B8 64 D2 04 sits in the 32 bit integer and the 1 vanishes into the ether. Convert back to decimal notation and you get -1201352188. This is what usually happens with a signed integer, but it's left up to whatever's beneath C++to decide what actually happens. – user4581301 Jun 28 '20 at 04:26
  • A note on the duplicate: a smaller type is being used, but the result is the same and the answer covers what's happening right down to the bits. – user4581301 Jun 28 '20 at 04:37
  • The result of `1234*5243*1142` exceeds the maximum that an `int` can represent on your platform (the standard only guarantees that an `int` can represent up to `32767`, although it appears your compiler has a 32-bit `int` that can represent up to about `2147483647`) so you get overflow. Formally, overflow of signed integral types is undefined behaviour (although that may change in a future standard). A typical result (not guaranteed by the standard) is a value that is very different than you expect (in your case, a large negative), such as truncating the result to fit in an `int`. – Peter Jun 28 '20 at 04:40
  • Also consider this link: https://stackoverflow.com/a/6462474/12861639 if you want to set the max sizes for you numbers for sure. – Ranoiaetep Jun 28 '20 at 04:50
  • Your C++ code should not even compile (missing semicolons). Check by reading [this C++ reference](https://en.cppreference.com/w/cpp) then try to compile using [GCC](http://gcc.gnu.org/) as `g++ -Wall -Wextra -g`. Use a debugger (such as [GDB](https://www.gnu.org/software/gdb/) ...) to understand the behavior of your C++ code. Next time, provide some [mre] in your question. – Basile Starynkevitch Jun 28 '20 at 04:59

1 Answers1

2

It's not a code, it's the value as stored in the integer result. You're experiencing integer overflow. An int can only hold values of a certain size, and when you exceed that size you end up with bit patters that aren't what you want but that are still storable in an int. Sometimes those bit patterns are the integer representations of negative numbers which is what's happened here.

You might consider using a larger integer type such as long or long long.

jkb
  • 2,376
  • 1
  • 9
  • 12
  • Note that you'll want that larger data type the whole way through. If you multiply 3 `int`s the multiplication will be done as `int` and will overflow before it can be stored in the larger type. – user4581301 Jun 28 '20 at 04:30
  • @user4581301 That's actually not true. When you do a `long * int` or `int * long`, the `int` would actually be cast into `long` and make it into a `long * long`. However, it is true that you might want to cast them manually, or even declare them into the same type, to eliminate any unintended behaviors – Ranoiaetep Jun 28 '20 at 04:44
  • 1
    Another possibility is using some [arbitrary precision arithmetic](https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic) library such as [GMPlib](https://gmplib.org/) – Basile Starynkevitch Jun 28 '20 at 04:53
  • @Ranoiaetep what you say is true, but that doesn't make my statement untrue. Multiply three `int`s and you will get an `int`. Them's the rules. Change one or more of those `int`s into a `long` and you'll get the behaviour you've described, but you've fundamentally changed the parameters. – user4581301 Jun 28 '20 at 05:24
  • @user4581301 Sorry, it was my bad, I thought you meant `int(3) * long(num)` for some reason – Ranoiaetep Jun 28 '20 at 05:37