C++ - Instancia de clase local única para toda la duración del programa

Question

Estoy trabajando en un motor de juego lil en C++, y decidí hacerlo todo OOPily (uso intensivo de clases) Está destinado a ser (teóricamente) cruzado plataforma, entonces tengo una clase 'Engine', una instancia de la cual es creada por 'OS Module', que es WinMain para Windows (la plataforma en la que estoy desarrollando).

Tengo tres preguntas principales :

1. ¿se considera una mala práctica para crear una clase que sólo se va a crear una instancia una vez en toda la aplicación? ¿Tal vez porque hay algún tipo de impacto en el rendimiento o gastos generales añadidos incurridos al usar una clase en lugar de un conjunto de funciones?

2. He estado planeando que WinMain cree la instancia de Engine como variable local. La clase Engine será bastante grande, con clases para rendering, análisis de scripts, material del sistema de archivos, etc. Básicamente, todo el motor del juego, aparte del código específico del SO, estará contenido en la clase Engine de alguna forma (posiblemente como una instancia de otra clase.) ¿Es una mala idea crear una instancia local de mi gran clase Engine dentro de la función WinMain? ¿Es una mala idea crear una instancia local cuando se creará la clase cuando se inicia el programa, y ​​finalizará cuando termine el programa? Tal vez nuevo sería mejor?

3. Mi plan (i/wa) s para dividir el motor en 'módulos', cada uno de los cuales está representado por una clase. La clase Engine contendría una instancia de casi todos los otros módulos, como, como se mencionó anteriormente, rendering, interacción del sistema de archivos, etc. ¿Es una mala idea utilizar clases como contenedores para módulos grandes desde cierta perspectiva (rendimiento, diseño, legibilidad?)

Gracias por cualquier ayuda :)

Answer 1

motores de juego no son los principales candidatos para cross-platform'ness ya que por lo general implican una interacción eficiente con bajo nivel de API (que no son cruzada platofrm).

El tamaño de una clase depende de las variables miembro que contiene, no del número de funciones que implementa.

El espacio de pila suele ser pequeño (http://msdn.microsoft.com/en-us/library/ms686774%28v=vs.85%29.aspx) mientras que el montón es teóricamente tan grande como la memoria RAM disponible. Entonces, si tienes algo realmente grande, guárdalo en el montón (con algo nuevo).

La "pantalla de bienvenida": no hace todo el trabajo al comienzo del programa. Los usuarios lo odian cuando ejecutan el programa y no se muestra nada en la pantalla porque su programa está ocupado inicializando algo ... Ejecución de instancias perezosas de búsqueda, básicamente no hacen cosas que pueden esperar y siempre muestran algo en la pantalla.

En cuanto a respuestas específicas: 1. No, suponiendo que no hay funciones virtuales, no debe haber una sobrecarga de rendimiento. 2. Vea "Pantalla de bienvenida" y "espacio de pila limitado" arriba. 3. La modularidad generalmente es buena, solo asegúrese de que cada clase haga/represente una sola "cosa". Pero no tienen tantas clases de empezar olvidar sus nombres y propósito :)

Answer 2

1. n, haciendo lo que hace que su limpiador de diseño y se recomienda más fácil de mantener.
2. No, el uso directo del almacén libre debe evitarse siempre que sea posible (es decir, no utilice new a menos que sea absolutamente necesario)
3. Ver # 1

Answer 3

1. No, no se considera mal estilo. De hecho no conozco los entornos de aplicaciones que van sin uno, y el famoso patrón Singleton es básicamente alrededor del mismo tema (pero diferente, que conste)

2. No me puedo imaginar que su clase es en realidad tan grande. Si es así, hazlo en el montón. Sin embargo, es probable que los contenidos reales de esa clase estén en el montón de todas formas (supongo que usarás clases de contenedor existentes, que 99 de cada 100 asignarán dinámicamente; esto vale para contenedores STL como bien)

3. ¿Qué diferencia haría si los coloca en el segmento de datos, como auto en la pila o miembros de una clase? Creo que la clase enfatiza la modularidad y podría permitirle hacer las cosas más fácilmente (como, por ejemplo, pruebas unitarias o reutilizar el motor para una versión de solo red, etc.)

Answer 4

¿Se considera una mala práctica a crear una clase que sólo se va a crear una instancia una vez en toda la aplicación ? Tal vez porque hay algún tipo de rendimiento golpeado o agregado gastos incurridos usando una clase en lugar de un montón de funciones?

No, en absoluto. Esto es básicamente porque su clase de aplicación puede hacer cosas como heredar y encapsular. No hay golpe de rendimiento o gastos generales añadidos.

He estado planeando tener WinMain crear la instancia del motor como variable local . La clase del motor se ser bastante grande, que contiene las clases para la representación, analizarlos mediante guiones, presentar cosas del sistema, etc. Básicamente, el motor del juego conjunto, aparte de OS código específico, estará contenida en la clase del motor de alguna formulario (posiblemente como una instancia de otra clase ). ¿Está creando una instancia local de mi clase de motor muy grande dentro de , la función WinMain es una mala idea? ¿Es la creación de una instancia local una mala idea cuando se creará la clase cuando se inicia el programa , y finalizará cuando finalice el programa ? Tal vez nuevo sería mejor?

No, esto es más o menos de la manera que debe ir. ¿Por qué molestarse en la distribución del montón? Quieres semántica de destrucción automática. A menos que su clase tenga un tamaño muy grande, cientos de KB o más, en cuyo caso una asignación de heap basada en RAII es más inteligente, ya que la memoria de la pila es bastante limitada. Es decir, un tamaño estático físico por instancia, según lo informado por sizeof(), sin incluir las asignaciones dinámicas.

Mi plan (i/wa) s para dividir el motor arriba en 'módulos', cada uno de los cuales es representada por una clase. La clase de motor contendría una instancia de casi todos los otros módulos, como, como mencionado anteriormente, la representación, presentar interacción del sistema, etc. está utilizando clases como contenedores de grandes módulos una mala idea desde una perspectiva (rendimiento, diseño, facilidad de lectura?)

Esto es exactamente lo que el diseño orientado a objetos es la encapsulación de lucro, y dividir el programa en módulos claramente definidos y separados, a continuación, crear instancias de cada uno que usted necesita, es exactamente la idea detrás de la programación orientada a objetos. El tamaño del concepto que encapsula una clase generalmente se considera irrelevante, siempre que sea un concepto único. Un diseño modular claro es genial.

Recomendaría utilizar la herencia en tiempo de ejecución para todos los dependientes de la plataforma, y ​​preferiblemente, cargarlos dinámicamente en tiempo de ejecución (usando la clase de SO para realizar la carga dinámica). Esto impone una sólida abstracción en tiempo de compilación y permite una compilación más eficiente.