next »

[JakobProgsch]

From my experience singletones aren't really better than just having the friggin globals in the first place. It's a pattern to enforce uniqueness. Not to justify globals. Sadly it is often used that way "I made it a singleton so it's ok!". In reality there are very few use cases where you really have to enforce uniqueness. Sure the typical use case of "TextureManager" objects is to have one... But there is no reason to enforce the typical use case.
I'm not sure why exactly, but the more I learn/gain experience the less I feel the need for globally accessible data anyway. Also the impulse to avoid them (and very "stateful" objects to begin with) comes from the realization that my code reuse comes almost exclusively from writing code that does not depend on any "state" be it global or not. Also it's a sure way screw up chances for nice paralleism, but i guess that is a minor concern for most.

[InfiniteStateMachine]

Yeah if you plan to do unit tests, something like the service locator pattern can be a nice replacement for singletons. Or you could just not have unit tests..

heh, I've gone this long without really touching them. I really should learn them just beucase TDD is getting popular.

That said I have trouble seeing their use in a game outside of a few special cases (perhaps that's a discussion for another thread though)

[Orz]

Usually when people argue about something this much, there's not much difference between the alternatives.  If there were, everyone would agree which was better.

I tried using extern variables but I am switching to singletons.  I was already putting my variables into their own files with init and cleanup functions, so it was more straightforward to just use a singleton.

@ThemsAllTook:  The strict singleton pattern sounds cool.  Do you have any examples?  I'm off to google it in case there are already a billion tutorials.

[ThemsAllTook]

The simple way is to use a private constructor. If you're in a language where you can't do that (pretty sure C++ can), your constructor would just have to check if the shared instance is already initialized and fail if it is.

[Evan Balster]

I initialize several registries in static time.  (Before main() is called or any concurrent threads can spawn)  These generally describe other pieces of code in the application such as drivers, plugins and reflected classes, and it wouldn't make much sense to model any mutable state with them.  The registry is filled by code called from global-static-value constructors, and locked before program execution starts.

Those are the only "globals" I make use of in my programming, save for occasional (and usually temporary) quick-hacks.  That's a bit of an unusual use-case, but a good one to be aware of as it's extremely useful in making code "optional" in compilation.

[oahda]

tl;dr use the best method for the project in question

Small games don't need to have a pretty solution at all.