Hello

I am intruiged to find out a bit about how people approach declerations of their classes within their C++ games/projects.

I usually declare global instances of my classes within my main.cpp file that I then extern into functions.cpp (etc). A bit sloppy maybe but hey-ho I'm impatient. But I hear (on the grapevine) that globals really ARE frowned upon, and I want to improve my behaviour in the 'best' way possible.

Do people generally have a singleton class, such as 'game' that contains instances of all the other required classes? Or do they create instances within, say, a 'game()' function and then pass them to the required functions?

Just looking for opinions really

Dizzy

In C#, I always use an dependency injection framework which handles the whole singleton issue for me. The object itself has no clue if it's a singleton or not.

For C++, I'm afraid it's not quite that easy. Googling IoC for C++ only reveals PocoCapsule which I have no experience with.

In general, I would try to stay away from global state as much as you can. But in some cases it can't be avoided without producing even worse code.

I dislike using singletons myself. You still end up with globals doing that. You could, I suppose, have your Game and GameEntity classes hold a parent pointer (NULL for Game, pointer to parent for everything else), and travel up the list till you hit NULL, then return the this pointer. Sometimes, you'll want to access an object's parent anyways, so this could be useful. If you want speed, you could copy the Game pointer to each GameEntity when it's created instead of having to traverse parents.

I second the "Inversion of Control" idiom mentioned by imaxcs. Haven't been doing any C++ coding as of late, so I too can't tell you if/how well it works.

A singleton is nothing but a wrapper class around a bunch of globals. The only thing you gain by using a singleton is that you can lazy-init your globals when needed, and that you can refactor it into a non-singleton class later, in case you have to. Another useful property of singletons is that you can have an actual constructor, but then, this also gives room to a lot of nasty "worst practices", such as constructors with side effects, etc. etc. yadda yadda.
Finally, there's the threading issue, which basically means that you need to make sure your singleton instantiation is properly protected, otherwise you might end up with more than one instance after all. And, depending on the situation, the term "single instance" is relatively vague; consider a web application of which several copies are installed (say, to provide some sort of load balancing or whatever) - do you want one copy per request, per session, per user, per application instance, per server, or one copy period?

Because it still encapsulates somewhat better than a plain bunch of globals. In most cases, however, there isn't a reason to enforce singleton behaviour. Even with the classic example of a data access layer that uses a singleton to represent the database connection, there is little reason to disallow a second connection, as long as you make sure all connections are closed under all circumstances. A singleton-like getDefaultInstance() method is still useful though.

Oh, and I have absolutely no clue at all how namespaces are supposed to be related. Namespaces avoid identifier name clashes while still allowing concise names, but I don't see how they can make globals any safer.

Yeah, I know, and I love namespaces for this, but globals in a namespace are just as global, with just as little control over which part of your (or someone else's) code uses them.