From and OO point of view, I really do think that passing references to the RNG is probably the right way to do it. But it's just such a pain in the arse, and I wonder if it's really worth it.

In my current project, the natural place for the RNG to live would be the Game class. Game only uses random numbers in a couple of places though. Most of the random numbers will be used by one of its members, the World class. There is only one World, so passing a reference to that is no problem at all; but after that it starts to get ugly. The World will had a bunch of Zones, each of which will need access to the RNG, and each zone will want to use a random map generator. And of course, a bunch of objects, features, characters and so on. All of these things might all want access to the rng - and I just think it's really ugly to have to pass an extra argument to every damn thing that ever gets created.

And this is why I made the thread. I feel that in this case, the OO design is going to make my code harder to write and harder to understand - and I'm just not sure it is worth it.

I'm reminded of when I did a C programming subject at university, we were meant to write a game (wumpus world) and they told us that we shouldn't use any global variables. I decided stuff that. That would mean that every single function is going to have an extra argument, and it will always be the same argument. It's just an inefficient way to code. I'm going to make a single global struct called "thegame".
Anyway, that's what I did, and I explained why... but I got marked down for it. I still think it was the right thing to do for that particular project.

I think you speak sense in most of your post, but I will still defend my decision about having a global "thegame" struct in Wumpus World! If the game was written in C++, I would have made thegame a class, and had a single instance in main() and it would not have been global. But in C, when every function in the entire program is essentially a method of thegame, I figure I might as well just write the code as if the entire thing is in thegame class; and main() is really just thegame.execute() with a different name. And if someone else was reading the code, I don't see how my way of doing it would be any harder to understand at all. If instead, every function passed a thegame pointer to every other function, people would still have to know what's inside thegame, and they would still know that it can be changed by any other function... Really. I don't see the difference except that having a global struct was a notational convenience. The only advantage I can think of for using the point-passing approach is that it would make it easier to run multiple instances of thegame from the same program - but I don't see how that feature could be useful in that particular project.

You really think adding an extra parameter to each and every function call is awesome? You're sick, dude.

A->screen
A->mouse_pos >> 16
A->pallette // ???
A->mouse_b & 1
A->key[KEY_ESC]

That is your idea of an improvement? I will never, ever, ever collaborate with you on any code, ever.

If you think this is impossible, then you really suck at coding. I have an entire library built around Allegro 4, and it works perfectly.

screen = 0x4f24; // Have fun, you poor bastard.

If you're dumb enough to do things like that, then your programs deserve to fail, and fail hard.

And now we have constructs like al_get_bitmap_width(bmp) where all you needed before was bmp->w. Also, now there is a ton of hidden state, which can bite you pretty hard if it changes in code that you forgot changes it.

If Allegro was a singleton, then you would never have newbies trying to create or load bitmaps before allegro was initialized, because they couldn't anymore. But I suppose if they had to pass a valid ALLEGRO_INSTANCE* to every single function they ever wanted to call then it couldn't fail either.

And the only way to enforce that is to use a singleton. Thanks for proving my point.

Really? Name one globally accesible variable provided by the C or C++ standard libraries? No, RAND_MAX and INTMAX and the like do not count. But I suppose we should all have to create an instance of struct CSTDLIB or class CXXSTDLIB to conform to your standards, and then call methods that operate on those instances.

Did you really just say that? What global state are you talking about? And just how exactly does that influence others to use global state as well?

Again, and again, there is nothing wrong with using global state where it is appropriate to do so. In my library, there are 69 variables declared extern, and they are meant to be accesible to other code that needs it. Why should I make an accessor function for each and every one of them? That's just stupid.

Also, who are you calling naive? I'm the one with a functional GUI and extension library, while all you seem to have is a bunch of failed projects hosted on GitHub.

What's hard to understand about a global variable? It's reference didn't get there magically, it got there through an #include statement. Ever heard of grep before?
grep -r -E -I -n "extern.*global_name" libs\include*.*
Wow, there it is.

He's the one who completed a game, so who are you calling naive? Look in the mirror buddy. He was perfectly justified in using a single global to give access to all the functions that needed to use it.

Also, every time I see you use the 'this' pointer inside a class to access member data or class methods I want to light my monitor on fire and cleanse it from displaying ugly pointless code.

When it comes to globals, you have Obsessive Compulsive Disorder. Get some professional help, and lighten up.

Append

No, it is not global, because you can't access it without the accessor function. Do you know what global means? If it wasn't declared as extern, or defined outside of main, it is not global (to code that includes your header). :P And there is nothing wrong with modules that use local globals either. :P

Maybe stdout etc aren't real global variables, but they do have at least some kind of global state mojo happening. Check this out:

int main(void)
{
  freopen("output.txt", "w", stdout);
  if (stdout)
    printf("Hello, world?\n");
    
  fclose(stdout);
    return 0;
}

This code compiles and runs, and puts the text in output.txt.

Also, as was mentioned earlier in this thread, the standard library's rand has a global state (or at least static) state.

They aren't variables. Replace stdout by (FILE *)1 in your code and you'll get identical executable.

The addition of the parameter isn't awesome. The elimination of the global state is awesome. The parameter is neutral. It doesn't hurt any to pass an extra parameter. Global state can and does hurt though.

I said a good framework. A good framework is one that is self-contained and safe to use. Something that you (or a n00b collaborator) can't easily fuck up just by typing the wrong operator.

It isn't about doing it on purpose (or necessarily at all). These are the kinds of things that happen accidentally. We are human. Humans make mistakes. Mistakes with global state can cost you a LOT more time than mistakes with limited-scope state. It doesn't even have to be you. Maybe you're collaborating with somebody, maybe they're hacking away at 4am, maybe they screw up and the compiler doesn't catch it. The program happens to run fine for them by chance and does everything they expected, so they commit and push. You pull in their changes and suddenly the entire program is crashing randomly. Have fun figuring out where the problem is.

Sure, you can just go on believing that you smarter than me, and the Allegro developers, and ... the world.

The hidden state is global state. That's the part that I'm still not happy with. Strangely, the way you want to fix it is by adding more.

Exactly. That is the point of dependency injection. It should become much more clear that you have a dependency to resolve before you can proceed.

Who said anything about enforcing it? It's really quite simple. Instantiate one and pass it throughout the application. You should know you only ever need one and should never create more than one (it would be the same as only needing one file and opening two; it's just wrong). If you do, however, it should still work as per normal. It might not do what the programmer wanted, but it should still do exactly what the object was intended to do.

std::cout.

Who says you should have to instantiate them? The runtime is instantiating them now. There's no reason it can't continue to instantiate them. The entry point of the program would just change.

Suddenly main controls what parts of the application have access to everything. Oh, but I know. Then you'd have to type another parameter. And maybe even think.

I already gave you an example. std::cout. There are many more where that came from in every language. It influences others using global state too because rather than bothering to pass an std::ostream into a function or method, most people will just default to directly accessing std::cout or std::cerr. This makes code inflexible and also gets them used to thinking in terms of globals. When they go to design their own class, they think how are they going to get their X into f? The answer is right there on the line above in std::cout. Make it global! NO.

I write code for a living. Code that I don't own and can't share. ;) The code on GitHub is the code that I have the time and energy to write in my spare time, which isn't much. Then again, I've seen your code quality, and I have no interest in using any of the code I've seen you write. ::) I'd be surprised if anyone other than you used it.

Do you know what global means? Apparently not. extern isn't limited to your file. I can declare your variable extern myself and access it. Nothing is going in to those example function calls so anything coming out has to have been created in the function or has to exist globally. There's no way around that.

stdin/stdout/stderr are still global because those constant numbers refer to file streams. I'm not sure of the details, but IIRC open files are stored in a table and the file descriptor (of which I'm not sure stdin, stdout, stderr directly are) are an index into this table. Regardless of the implementation details, these numbers grant you access to these file streams from anywhere in the application, so they are global. It's no different than knowing a pointer for some random object. If you can know the address from anywhere in the program then you can access the data and it is effectively global.

That makes it pretty much impossible to control a program's or library's access to the standard streams. That might not seem like a problem, but imagine you (not just Audric; I'm speaking to all readers now) have some complex program to write and for whatever reason there's some part of it that you don't want to write (maybe you don't have the expertise, maybe you don't have the time, maybe it's against your religion; it's hypothetical). Meanwhile, you find the one library on the face of the Earth that does exactly what you want! The only caveat: the library is reading from stdin or writing to stdout or stderr directly and the project specifications are very strict about user-interaction and output; and these unauthorized reads and writes violate the spec. :-/ The library is made inflexible by accessing the global state of these standard streams, and in this contrived hypothetical example, it makes it worthless. The programmer is doomed. The end.

It is certainly convenient to have these global streams, but it's certainly not necessary, and the industry has learned the hard way that unnecessary global state is expensive (in terms of programmer time and software liability). That's why it's generally agreed upon now that global state is bad practice and that you should avoid it whenever possible. The standard streams are certainly a good idea, but I think it would be better if the OS abstracted them more and passed them into the entry point (e.g., main) in some way instead of making them global.

Static state is global state. They are the same thing. A static variable is not necessarily a "global variable" (but that's just language semantics), but it is still global state.

Actually, errno is a perfect example of global state that causes problems. For starters, it isn't obvious which functions use it and which ones don't. You have to go memorize the manual for every library and module of your program to know. It reports errors so it certainly does matter (albeit, a lot of your code seems to ignore errors outright, so no surprise you think it doesn't matter). Handling errors often means calling more functions that may set errno. It makes robust error handling very difficult. Probably why exception handling was invented to replace it. :P

That's actually not absurd. Many libraries do exactly this. It's a rather powerful and flexible system. Of course, exception handling is effectively the same exact thing, except instead of passing an object in to be filled with error information, the object with error information is created where the error occurs and copied (or "referenced" in one or another sense of the word) to the handler block.

If a Singleton has state that can be affected from outside in ways that would affect the way it behaves then it's no different (hint: basically any useful Singleton will, unless it's just returning a constant :P). The fact that the program crashes when you invalidate the screen pointer is irrelevant. It could have been a simple counter or string. Making it invalid will produce incorrect results from the software. If a program isn't doing the one right thing then then it's broken and useless.

About your case with the library "that does everything you need, except (...)" :
In the end, if you don't have access to the source code, you always lose :/

At work, even in C# which has great language facilities (starting with hierarchical namespaces), I have seen many cases where something is planned for reusal (being re-used?) but no matter what, by the time it is operational, the new callers have subtly different needs.

edit: To James Lohr : I think it's important to not give the same advice to people who are learning or fluent in a language (library etc), and whether the result is an indie game prototype (that has 75% chance not getting to the "mostly finished" phase), or a professional piece of code that is going to "earn its pay" for several years.

/dev/urandom is a pretty cool resource; but I'd still always build the PRNG into my program, for efficiency and control.

For example, awhile back I wrote a physics simulator which needed a huge amount of random numbers. I used the mersenne twister, as usual, but I used /dev/random for the seed. (Having a good seed was important because I was running 10 - 20 instances of this program at a time. Seeding with time(NULL) would have been a disaster.)

While we're on the subject of RNGs instead of global variables, I should mention that I've written a OO C++ RNG library, which comes in 2 flavors, one for RNG users, one for RNG researchers (the research one also includes statistical tests and some deliberately flawed RNGs).

It's available at https://sourceforge.net/projects/pracrand/files/

Actually, even on the subject of OO design and/or global state, I'd be interested in any comments on the design of the library. The only global state is internal to the auto-seeding mechanism, though I do advise users to declare a global RNG or global/TLS RNG unless they need multiple RNGs.

Typical usage looks like this:

#include "PractRand_full.h"
#include "PractRand/RNGs/jsf32.h"
PractRand::RNGs::Polymorphic::jsf32 rng(PractRand::SEED_AUTO);
int main(int argc, char **argv) {
  PractRand::initialize_PractRand();
  std::cout << "random uniform int in [0,6): " << rng.randi(0, 6) << std::endl;
  return 0;
}

While the code there calls initialize_PractRand(), that is not actually necessary unless the first usage of SEED_AUTO occurs in re-entrant code.

Various details:
- RNGs selection: wide variety of recommended RNGs with different strengths & features. Documentation that lists all recommended RNGs with their respective strengths in easy to compare format, though much of that is subjective.
- legal issues: Unencumbered, mostly public domain.
- RNG interface: Each recommended RNG is available as either a polymorphic class (for convenience) or a raw implementation (for maximum control & performance).
- Performance: Almost all of the recommended RNGs are fast. Some are very very fast. Most are optimized. Some seed very quickly. I also attempt to keep header size relatively small to maximize users compilation speeds.
- RNG seeding: during construction each full RNG requires either a 64 bit integer as a seed or PractRand::SEED_AUTO (which tells the library to generate a seed automatically) or PractRand::SEED_NONE (which tells the library that you plan to seed this RNG at a later time), or another RNG (which is used to generate a random state for the new RNG). Special entropy-pool classes (which are also RNGs) are available to help users wishing to engage in more complex seeding schemes.
- RNG distributions: all full RNGs offer a built-in minimum set of basic distributions - raw 8/16/32/64 bit words, uniform floating point & integer numbers, and a few variations on that. In addition to the basic distributions they also are compatible with Boost/C++0x distributions.
- RNG exotic usage: support for things like serialization, entropy pooling (not supported on most RNGs), random access (not supported on most RNGs), etc