On A different note, this code:
rand()%6
is generally regarded as a bad practice. the lower bits of rand() are significantly less random than the higher bits. You'll get better randomness if you do:
(rand() >> 8)%6
for instance.
EDIT:
For more detail on this, see this note and also this article from Dr. Dobbs journal which at least hint at the reason:
Note: Do NOT use
y = rand() % M;
as this focuses on the lower bits of
rand(). For linear congruential random
number generators, which rand() often
is, the lower bytes are much less
random than the higher bytes. In fact
the lowest bit cycles between 0 and 1.
Thus rand() may cycle between even and
odd (try it out). Note rand() does not
have to be a linear congruential
random number generator. It's
perfectly permissible for it to be
something better which does not have
this problem.
DDJ:
The most important point is that the
lower bits of the output from the
usual (linear congruential) random
number generators are the least
"random." That is, patterns in the
lower bits are common. Hence, the
output from the routine roll in your
discussion is not surprising. Also, it
is avoidable by relying on the upper
bits to determine the integer
returned.
For example, if you wanted to choose a random "true" or "false" value, and you used the code:
rand() % 2
Then you might end up seeing the pattern of results:
1,0,1,0,1,0,1,0,1,0 (etc)
This is obviously not that random, but it is a property of the linear congruential generator that might be in use. A better scheme altogether (for C++) might be to use the Boost.Random library which has support for all kinds of pluggable random generators (including Mersenne Twister which does not have this flaw).