C++ - Single local class instance for entire program duration

I'm working on a lil' game engine in C++, and decided to do it all OOPily (heavy use of classes.) It's intended to be (theoretically) cross-platform, so I have an 'Engine' class, an instance of which is created by the 'OS Module', which is WinMain for Windows (the platform I'm developing it for first.)

I have three main questions:

1. Is it considered poor practice to create a class that is only going to be instantiated once in the entire application? Perhaps because there is some kind of performance hit or added overhead incurred by using a class rather than a bunch of functions?

2. I've been planning to have WinMain create the instance of Engine as a local variable. The Engine class will be fairly large, containing classes for rendering, script parsing, file system stuff, etc. Basically, the whole game engine, apart from OS specific code, will be contained in the Engine class in some form (possibly as an instance of another class.) Is creating a local instance of my very large Engine class within the WinMain function a bad idea? Is creating a local instance a bad idea when the class will be created when the program starts, and end when the program ends? Maybe new would be better?

3. My plan (i/wa)s to divide the engine up into 'modules', each of which is represented by a class. The Engine class would contain an instance of almost all the other modules, like, as mentioned above, rendering, file system interaction, etc. Is using classes as containers for huge modules a bad idea from some perspective (perform开发者_JS百科ance, design, readability?)

Thanks for any help :)

Game engines are not prime candidates for cross-platform'ness since they usually involve efficient interaction with low-level API's (which are not cross-platofrm).

The size of a class depends on the member variables it contains, not the number of functions it implements.

Stack space is usually small (http://msdn.microsoft.com/en-us/library/ms686774%28v=vs.85%29.aspx) while the heap is theoretically as big as available RAM. So, if you have something really big, store it on the heap (with new).

The "Splash Screen": don't do all the work at the beginning of the program. Users hate it when they run the program and nothing shows on screen because your program is busy initializing something... Lookup lazy instantiation, basically don't do things that can wait and always show something on screen.

As for specific answers: 1. No, assuming no virtual functions, there should be no performance overhead. 2. See "Splash Screen" and "limited stack space" above. 3. Modularity is generally good, just make sure each class does/represent a single "thing". But don't have so many classes you start forgetting their names and purpose :)

Is it considered poor practice to create a class that is only going to be instantiated once in the entire application? Perhaps because there is some kind of performance hit or added overhead incurred by using a class rather than a bunch of functions?

Not at all. This is basically because your Application class can do things like inherit and encapsulate. There's no performance hit or added overhead.

I've been planning to have WinMain create the instance of Engine as a local variable. The Engine class will be fairly large, containing classes for rendering, script parsing, file system stuff, etc. Basically, the whole game engine, apart from OS specific code, will be contained in the Engine class in some form (possibly as an instance of another class.) Is creating a local instance of my very large Engine class within the WinMain function a bad idea? Is creating a local instance a bad idea when the class will be created when the program starts, and end when the program ends? Maybe new would be better?

Nope- this is pretty much the way it should go. Why bother heap allocating? You want automatic destruction semantics. Unless your class has a very large size, hundreds of KB or more, in which case an RAII-based heap allocation is smarter, as stack memory is quite limited. That is, a physical per-instance static size as reported by sizeof(), not including dynamic allocations.

My plan (i/wa)s to divide the engine up into 'modules', each of which is represented by a class. The Engine class would contain an instance of almost all the other modules, like, as mentioned above, rendering, file system interaction, etc. Is using classes as containers for huge modules a bad idea from some perspective (performance, design, readability?)

This is exactly what object-orientated design is for- encapsulation, and dividing the program up into clearly defined and separated modules, then instantiating each one that you need, is exactly the idea behind object-orientated programming. The size of the concept that a class encapsulates is usually considered to be irrelevant, as long as it's one single concept. A clear modular design is great.

I would recommend using run-time inheritance for all of the platform-dependent ones, and preferably, loading them dynamically at run-time (using the OS class to perform the dynamic loading). This enforces a solid compile-time abstraction and allows for more efficient compilation.

1. No, doing whatever makes your design cleaner and more maintainable is recommended.
2. No, direct use of the freestore should be avoided whenever possible (i.e., don't use new unless you absolutely have to)
3. See #1

1. No it isn't considered bad style. In fact I know no application frameworks that go without one, and the renowned Singleton pattern is basically around the same theme (but different, mind you)

2. I can't imagine that your class is actually that big. If it is, make it on the heap. However, chances are that the actual contents of that class are going to be on the heap anyway (I'm sort of assuming you'll use existing container classes, that wil 99 out of 100 do dynamic allocation; this goes for STL containers as well)

3. What difference would it make whether you put them in the data segment, as auto's on the stack or members of a class? I think the class emphesizes the modularity and might enable you to do things more easily (like e.g. unit testing, or reusing the engine for a network-only version etc. etc.)