why plus can be minus. Another of Microsoft's trick?

[claude uq]

What could be a simpler snippet than this

#include <iostream>
using std::cout;
using std::endl;

int main() {

long nx = 200L;
long ny = 300L;
long gridSize = 0L;
long var = 0L;

gridSize = nx*ny;
var = gridSize*gridSize;
cout<<gridSize<<" "<<var<<endl;

system("pause");
return 0;
}

When executed, the above streams out 60000 for gridSize and -694967296 for
var !!!

Tried on a few machine, still same. What's going on here.

 

[Phlip]

long nx = 200L;
long ny = 300L;
long gridSize = 0L;
long var = 0L;

gridSize = nx*ny;
var = gridSize*gridSize;
cout<<gridSize<<" "<<var<<endl;

system("pause");
return 0;
}

When executed, the above streams out 60000 for gridSize and -694967296 for
var !!!

Tried on a few machine, still same. What's going on here.

Hit <Logo+R>calc<Enter> to raise the MS Windows Calculator. Select
View->Scientific. Enter 60000. Hit the square button (x^2). The result
(formatted for clarity) is 3 600 000 000.

Now switch to Hex mode with the radio button "Hex". Enter 7fffffff - which
is the maximum value of a signed 32-bit long integer. Switch the Mode back
to Dec. The number converts to 2 147 483 647. That's less than 3.6 billion.

Blaming MS is fun, but you over-flowed the long. The system ran out of bits
to store the entire number, and simply shoved the lowest 32 into a register.
The highest bit was set, so the number appears negative.

C++ code runs very lean and efficient because it passes the question what to
do at integer overflow time back to the programmer. Most of the time the
answer to this question is nothing, because we either count natural numbers
of whole things in user-comprehensible units, or we use 'double' to store
the huge numbers.

 

[claude uq]

Hit <Logo+R>calc<Enter> to raise the MS Windows Calculator. Select
View->Scientific. Enter 60000. Hit the square button (x^2). The result
(formatted for clarity) is 3 600 000 000.

Now switch to Hex mode with the radio button "Hex". Enter 7fffffff - which
is the maximum value of a signed 32-bit long integer. Switch the Mode back
to Dec. The number converts to 2 147 483 647. That's less than 3.6 billion.

Blaming MS is fun, but you over-flowed the long. The system ran out of bits
to store the entire number, and simply shoved the lowest 32 into a register.
The highest bit was set, so the number appears negative.

C++ code runs very lean and efficient because it passes the question what to
do at integer overflow time back to the programmer. Most of the time the
answer to this question is nothing, because we either count natural numbers
of whole things in user-comprehensible units, or we use 'double' to store
the huge numbers.

Well, thanks for this. I was aware that the type long has a range of about
+- 2 billions .

In my stupide head, 60000 square was below 2 billions. Mea Culpa and yes,
sorry Bill

 

[Chris Mantoulidis]

Well, thanks for this. I was aware that the type long has a range of about

+- 2 billions .

In my stupide head, 60000 square was below 2 billions. Mea Culpa and yes,
sorry Bill

What about "unsigned long"? It's like 4bil something max... And as I
can see you don't need negative values...

cmad

 

[John Carson]

What about "unsigned long"? It's like 4bil something max... And as I
can see you don't need negative values...

cmad

The supplied code used long, not unsigned long. If you change the longs to
unsigned long, then the code does indeed work.

 

[Phlip]

The supplied code used long, not unsigned long. If you change the longs to
unsigned long, then the code does indeed work.

But it would still overflow my sane subset. Instead of numbers that might
get anywhere near their limits I would either use a 'double' or a BigInt
(Google for the latter - it's not bundled with C++).