int randvar=rand()%100; //not working

int randvar=rand()%100; //not working

Hi, If i use the line above it generates the same number (7) each time on my system (osx10.3). Doe anyone know why this happens? Something wrong with the code maybe?

The code is complied with xcode 1.5, which calls g++ (3.2?) for the complie.

Thanks,

Gir.

1) it's rand() % 100, not rand() 100 %
2) include <ctime> and call srand(time(NULL)) before generating a random number. This seeds the random generator.

http://faq.cprogramming.com/cgi-bin/...&id=1043284385

Okay working. (btw - the 100% was a typo, I had it right in the code).

I used :

srand(time(NULL));

Thanks,

Gir.

you can also use srand(time(0)), which some peole are say is better because it avoids the user of a macro.

Originally Posted by major_small

you can also use srand(time(0)), which some peole are say is better because it avoids the user of a macro.

this is considered bad practice by most...

Originally Posted by The Infinite Wisdom of Man Pages

SYNOPSIS
#include <time.h>

time_t time(time_t *t);

you'll notice from the infinite wisdom of the man pages that the time() funtction takes a pointer to a time_t variable. NULL represents a pointer to nothing, 0 is a number not a pointer. Its unintuitive to use 0 when a pointer is expected.

That's debatable. Some (including Stroustrup) prefer using 0 instead of NULL to refer to a null pointer.

Originally Posted by Perspective

you'll notice from the infinite wisdom of the man pages that the time() funtction takes a pointer to a time_t variable. NULL represents a pointer to nothing, 0 is a number not a pointer. Its unintuitive to use 0 when a pointer is expected.

I disagree with you here. I don't find it unintuitive.

0 can represent the integral number zero, a floating point value of zero, the terminating null character or the null pointer.

Code:

//0 can represent many things
int i = 0;
long i = 0; //or 0l
float f = 0; // or 0.0f
char c = 0;// or '\0'
void* p = 0; //or ((void*)0)

Whats more intuitive about 'NULL' than '0'? Nothing about 'NULL' states that it is a pointer other than convention, and newbies don't know anything about convention anyway.

In a way, NULL isn't really part of C++, it is an old macro that resides in <cstdlib> for compability with C.
In the old days, the definition of a NULL macro was justified, but now '0' can be converted to any pointer type without explicit conversion.

Originally Posted by Perspective

this is considered bad practice by most...

I really can't argue with you about style, but there are many (including Bjarne Stroustrup as stated above) that don't consider this a bad style at all.

well, i can only speak about my own experiences and what i have learned in university. Assigning a pointer to 0 instead of NULL, or a char to 0 instead of '\0' are things that my professors consider bad practise. Thats just the way ive been taught, to each his own i guess.

Originally Posted by Perspective

well, i can only speak about my own experiences and what i have learned in university. Assigning a pointer to 0 instead of NULL, or a char to 0 instead of '\0' are things that my professors consider bad practise. Thats just the way ive been taught, to each his own i guess.

well, teh char '0' and '\0' are two completely different things... you can't use them interchangably, but in most instances (AFAIK), NULL is defined as 0, and one of mr. Stroustrup's greatest visions for C++ was to get rid of the use of macros.

Originally Posted by major_small

well, teh char '0' and '\0' are two completely different things... you can't use them interchangably,

i never said you could. my post says 0 and '\0'.

Originally Posted by major_small

but in most instances (AFAIK), NULL is defined as 0, and one of mr. Stroustrup's greatest visions for C++ was to get rid of the use of macros.

Correct.
In C++, NULL is defined like this: (in cstdio)

Code:

#define NULL 0

And yes, macros should be used extremly sparingly in C++. Inclusion guards is one example of valid use, debug statements another.

>this is considered bad practice by most...
Yes, but not for the reason that you intended. Let's say for the sake of argument that we follow the convention of not using NULL in favor of 0:

Code:

#include <cstdlib>
#include <ctime>

...

std::srand ( std::time ( 0 ) );

This is all well and good, right? Well, no, not really. time_t is a funky little creature that is highly restricted by the C++ standard. Basically all you can be sure of is that it is an arithmetic type that can be compared to -1 cast to time_t. For the most part you can expect this to work:

Code:

std::srand ( static_cast<unsigned int> ( std::time ( 0 ) ) );

But it still isn't portable because you have no idea what the type or representation of time_t is. A good solution I've seen suggested is to take a hash of the bits rather than using the value directly:

Code:

#include <cstdlib>
#include <ctime>
#include <iostream>
#include <limits>

unsigned int get_seed()
{
  time_t now = std::time ( 0 );
  unsigned char *p = reinterpret_cast<unsigned char *> ( &now );
  unsigned int seed = 0;

  for ( size_t i = 0; i < sizeof now; i++ )
    seed = seed * ( std::numeric_limits<unsigned char>::max() + 2U ) + p[i];

  return seed;
}