This too should have been simple and I expected it to be completed in a day. However, my treacherous tools turned upon me. As you can see in this thread, my preferred compiler (well, on Windows at least) and the near-standard Boost library don't seem to agree on a certain piece of code and this brought my work to a halt.
Now, the fact is, I could have rewritten the code in seconds to get it to work. I could even have used the modulus method on the standard random number generator and the slight bias would have been unimportant in this project. But I like to do things the right way, and learn in the process. So I posted here, to see if it was just me or if it was the compiler/library. I searched the web to see if anyone else had the same problem. (Doesn't appear they have.) I browsed the library source to see if there was some sort of configuration option I'd missed. I downloaded and installed the latest compiler service pack in case it was addressed in an update. I got as far as finally considering upgrading my compiler to the Visual C++ Toolkit 2003 or the latest version of Dev C++/MinGW in the hope of getting this one line of code to work.
Was this the high level, software engineering equivalent of the people who worry about optimising x++ vs. ++x, or about whether to use std::deque or std::vector on a collection of 10 objects? I don't like to admit it, but maybe it is. I was getting stuck on a tiny and unimportant detail; whereas it is performance for them, it's standards-compliance for me.
I allowed a trivial hindrance to turn into a project-delaying issue, and I'd like to think I've now recognised the futility of that. None of these compilers, development tools, or libraries are perfect, just as no significant piece of code is perfect, so there comes a point where you just have to accept the limitations of whatever technology you're using and code around them.