C++ Variable question

[BENCHMARKMAN]

The largest number you can put into an int is 4294967295. Now lets say I'm using an int as a counter and the counter hits 4294967296. What happens? Does the variable reset to 0 or is is unpredictable what will happen?

 

[Earp]

Actually, that value is for an unsigned int. An int's max value is only about half that (2^31 - 1).

It's been a while since I've written much in c++ (I program in c# mostly these days), though I believe you will just overflow back to zero.

 

[BENCHMARKMAN]

I'm asking because I need to do a priority queue that is FIFO and the professor suggested a counter but then also made the point that what happens when you hit the max range. He said he knew a way around this. I was thinking of having a counter counting how many times the insert counter had flipped back to zero.

 

[tim_m]

couldn't you just use a long, or say, an unsigned long long to just put off the problem?

 

[Lord of Shadows]

a 32bit int will have a maximum of (2^32 / 2) - 1 adding one to that will result to the negative maximum of -(2^32 / 2)

A unsigned 32 bit int will have a maximum of simply 2^32 - 1, adding one to this maximum will result in zero.

Example...

#include <stdio.h>

int main(void)
{
	int x = 2147483647;
	unsigned y = 4294967295;
	printf("%d %u\n", ++x, ++y);
	return 0;
}

Output:
-2147483648 0

 

[Earp]

As a general rule of thumb, if you are relying on/expecting arithmetic overflow to happen in a higher-level programming language (it's ok in assembly), you should rework your algorithm for better readability.

 

[BENCHMARKMAN]

I'm not expecting an overflow but I'm embracing for the possibility. The chance of doing over 4 billion insertions in a priority queue is small but it *could* happen.

 

[Elledan]

I'm not expecting an overflow but I'm embracing for the possibility. The chance of doing over 4 billion insertions in a priority queue is small but it *could* happen.

Overkill is only a bad thing if there are space constraints

 

[mikeblas]

I'm not expecting an overflow but I'm embracing for the possibility. The chance of doing over 4 billion insertions in a priority queue is small but it *could* happen.

Say you've got four gigs of memory. You've also got four gigs of elements in your priority queue. To fit in memory, you'd have no room left for a code or operating system, each element would have to be one byte long, and you'd have no overhead in the element for a key.

You'd need a neat algorithm for spilling your queue to disk, so I guess it could happen. Planning for that, you'd want to pick a type larger than an unsigned integer, or write code that defends against the overflow.

So maybe you're writing this for a 64-bit system. You'll suddenly find there that the size_t type is a 64-bit quantity, so no you have enough room to store a count of what could be a potentially very large address space.

But to your original question: it depends. Some processors will throw an exception when an integer overflow occurs. Some processors are configurable to throw or not throw an exception. Some processors wrap around.

X86 and I64 processors will wrap the result around and set a flag. The flag is ignored by every C/C++ compiler I've used on these platforms, but could conceivably be used to check the result and then throw an exception in software.

The language itself doesn't say what happens when the results are invalid. See section 5, paragraph 5:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined, unless such an expression is a constant expression (5.19), in which case the program is ill-formed. [Note: most existing implementations of C++ ignore integer overflows. Treatment of division by zero, forming a remainder using a zero divisor, and all floating point exceptions vary among machines, and is usually adjustable by a library function.]

So, it's predictable what will happen when you wrap the value around -- but making that prediction depends on the implmentation of the compiler you're using, as well as the processor you're running your program on.

 

[BENCHMARKMAN]

The counter would count inserts, the queue could be a max size of 100 but there could be removals in between. So it would be possible to hit over 4 billion because things could be removed.

 

[Stuh505]

Yeap, this is what crashed this rocket:

http://www.around.com/ariane.html

 

[Earp]

why are you keeping a counter of the total number of inserts that have ever been made to a queue?

 

[BENCHMARKMAN]

Its a Priority Queue that needs to be FIFO and in a Heap Array.

 

[mikeblas]

Yeap, this is what crashed this rocket:

http://www.around.com/ariane.html

Looks to me that it was more about a qustionable and unprotected type cast than an arithmetic wraparound.

 

[CHollman82]

nvrm

 

[CHollman82]

nvrm

 

[BENCHMARKMAN]

Can you tell me how I could declare and unsigned long that could take a size of 4294967295.

 

[Lord of Shadows]

That will fit in a plain old unsigned int.

unsigned num; // 32 bit unsigned number
unsigned int num; // same as above just explicitly said int, which is assumed and doesnt really need to be there;

unsigned long; // see below
unsigned long int; // should be 32 bits might vary on x86-64, but would give you more bits in most cases if not 32, check whatever file it is that tells you this stuff if you care that much.

 

[mikeblas]

int sizes don't vary between Win32 and Win64. size_t does, however.

 

[zappa86]

If you need more than 2^32 than you either need to make a large int storage class or get one off the internet.

 

[mikeblas]

If you need more than 2^32 than you either need to make a large int storage class or get one off the internet.

It depends on your compiler. For Win32, the Windows types DWORD and ULONG both map to "unsigned long", wich is large enough.

Win32 compilers must also suport 64-bit integers. LARGE_INTEGER wraps this type for the Win32 API, and the compiler's native type is __int64. This type can be unsigned, too, as "unsigned __int64".