I received these questions a number of times during the lab and afterwards from several different parties:
The short story is that you must call srand() before you call rand(), and you must pass srand() some kind of integer value. The current time of day is a common choice, for reasons I will discuss below.
When you give srand() an argument, you are "seeding" the random number generator.
What you then must do is, when a random number is required, call the rand() function. This returns a "pseudorandom" integer in the range 0 to some compiler-dependent value. You might then adjust this number with the modulo % operator to fit into some required range.
You need only call srand() once, before you call rand(). srand() is a void function: it only "seeds" the random number generator; it doesn't actually fetch a random number as well. rand() is the function which actually returns random numbers on demand. srand() has nothing to do with it.
But why do you need to "seed" the random number generator?
The problem with generating a series of "random" numbers is that, in short, the computer has absolutely no way of doing it. Computers can only perform mathematical operations, like addition and multiplication. Everything a computer does, from drawing a picture on the screen to playing a sound file to browsing the Internet, essentially breaks down into millions of little, tiny steps, like comparing two numbers or storing a number in a certain place in memory.
Now, the problem with "random numbers" is that true "randomness" is impossible to obtain using mathematical algorithms and formulae (because they always return a well-defined, and therefore by definition, "nonrandom" result.) Our concept of "randomness" is defined by macroscopic events whose outcome is hard to predict, like rolling a pair of dice or drawing a card from a well-shuffled deck. It is often, more formally, defined microscopically by atomic events like radioactive decay: by the whimsical behavior of quantum particles. Computers of course have no way of simulating "rolling dice" or "radioactive decay" on the low level.
But what computers can do is take a number, perform some mathematical function on it, and return the answer. It can even use the answer in the formula again, and get a different number.
If the function the computer uses has a sufficiently wide "spread" and sufficiently erratic behavior (there are established, strict tests for these things in statisitics) the numbers it returns will behave in a roughly random way. We call a function like this a random number generator.
But the first thing it needs is a suitably chosen number to start with. If it uses the same number all the time, it will return the same results every time. Computers do not have a will: they can't just pick a number that "feels good" and go with it. Remember, a function is defined to return "b" if "a" is given to it. If you give it the same "a" everytime, it will return the same "b" everytime.
This is what srand() is for. It tells the computer what the first number in the series will be. This number will be used to compute the random numbers you might ask for later. It starts the ball rolling, as it were.
This is what the book means when it says that rand() isn't truly random. No computerized algorithm is truly random... we call it "pseudorandom"... meaning that it might look random, it might taste random, but at the lowest level, when all of the coverings are removed, there is an actual, mathematical method to the numbers... there's a pattern. It isn't really random, though through all the smoke and mist it kinda looks that way... which is usually good enough.
But srand() doesn't return any random numbers. It just tells rand() what number to start with.
Of course, if you want a really random series, you need to have a somewhat random number to give to srand(). That's why we use the time of day. Since it's unlikely that the program will be run twice at exactly the same time of day, each time it's run, it appears to have a different sequence of random numbers.