"Bruno Medeiros" <brunodomedeirosATgmail@SPAM.com> wrote in message news:e4ngb0$24g4$1@digitaldaemon.com...

> I do something very similar:
>
>   int main(char[][] args)
>   {
>     // .. proccess args..
>     // ..maybe load some libs (like Derelict)..
>     App.appmain();
>     return 0;
>   }
>
> However, in my case, App is a module. If you only have one Context, and it is allways active during the program lifetime, why bother creating a singleton instead of simply using a module?

At least in my case, the nice thing about having a context class is that I can derive from it.  I can create some other predefined contexts (i.e. which set some things up for you automatically, or which are designed for a specific type of program in mind), and by giving them some abstract methods meant to be overriden, I can create "framework" contexts which are ready-to-use and which can just be derived and have the extra parts filled in.  That, and a compiler error (an "unimplemented abstract method" error) is nicer than a linker error saying that it can't find an undefined, mangled symbol.

Bruno Medeiros wrote:

> 
> However, in my case, App is a module. If you only have one Context, and it is allways active during the program lifetime, why bother creating a singleton instead of simply using a module?
> 

It's not really a singleton that I am using. It's an abstract class that sets a specific variable once when the first instance is constructed. You can create as many instances as you want after that. In my case, it is used in conjunction with a stack-based task (or state) system

In a game, you have different game state transitions. The title screen, multiple menu screens, the game play screen, and so on. Encapsulating all of these into state instances and using a stack to manage them makes it easy to transition from one state to another and back.

The example I gave is not how I'm actually using it, but close enough. The first state instance that is instantiated is added to the state manager as the default state and is never removed from the stack. This is done in the constructor of the abstract base class, allowing the game engine to maintain control flow and do a lot of core setup (reading config files, initializing the display and audio systems, and so on) behind the scenes.

The primary state instance is created in a static module constructor. I pass that module to Build, which can then compile the entire game engine along with it if I don't precompile it in a library first. I can implement multiple games by implementing different modules with static constructors that instantiate a default state and pass those to Build instead. And, if I wanted, I could implement the entire game using one state and never bother implementing others to transition to. It's a pluggable system that abstracts away quite a bit.