STL para juegos, sí o no? [cerrado]

144

Cada lenguaje de programación tiene su biblioteca estándar de contenedores, algoritmos y otras cosas útiles. Con lenguajes como C #, Java y Python, es prácticamente inconcebible usar el lenguaje sin su lib estándar.

Sin embargo, en muchos juegos de C ++ en los que he trabajado, no utilizamos el STL en absoluto, utilizamos una pequeña fracción o utilizamos nuestra propia implementación. Es difícil saber si esa fue una decisión acertada para nuestros juegos, o simplemente por ignorancia de la STL.

Entonces ... ¿el STL encaja bien o no?

munificente
fuente
14
El EASTL es una buena lectura open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
Matias Valdenegro
1
Sí, eso es lo que quise decir con "utilizamos nuestra propia implementación". :)
munificent
3
Si tienes la oportunidad de localizar y comprar gemas de programación Best of Game, hazlo. Hay un título de artículo "Uso de la STL en la programación de juegos" de James Boer, ArenaNet, donde hace un muy buen caso al usar la STL.
chiguire
En realidad, usar Java sin su lib estándar es bastante concebible, se llama J2ME: p
Bart van Heukelom
1
Gran pregunta!
Alan

Respuestas:

191

Cuando trabajaba en el desarrollo profesional de juegos, STL era demasiado inmaduro e hinchado. Pero eso fue hace> 10 años.

Ahora trabajo en simulación militar, que tiene requisitos de rendimiento aún más estrictos (como la velocidad de fotogramas nunca puede ir por debajo de algunos FPS). En la simulación militar, STL se usa en todo el lugar.

Algunas de las personas que le dicen que no use STL usan el argumento de que no siempre es la solución perfecta o incluso la mejor para el problema. Pero esa no es una respuesta a la pregunta. La pregunta debería ser: ¿hay algo inherentemente incorrecto con el uso de STL en los juegos? Yo diría que no, la mayoría de las veces, STL es una mejor implementación que la que un usuario inventaría por su cuenta.

Solo asegúrate de saber cómo usar el STL y úsalo en tu juego. Lea algunos libros y mire el código de implementación en el STL que está utilizando.

kevin42
fuente
49
Este es un consejo bastante sólido. El meme "STL es lento" no ha sido cierto durante al menos cinco años y probablemente mucho más. Continuará viviendo, al igual que las tonterías "Java es lento" y ".NET es lento", hasta que sea evidente para todos que ya no es el caso. El STL te ayuda a escribir mejores programas; Llegaría a decir que no usarlo, en la mayoría de los casos (aparte de ese 0.1% en alguna parte), es irresponsable. (Las afirmaciones de que no encaja en un dominio de problema dado son a menudo más una acusación de la forma en que se abordó el problema, no el STL en sí. Arregle su código, amigos.)
Ed Ropple
55
@Ed Ropple: Creo que el problema no es que STL no se ajuste a un problema dado, el problema es que se ajusta a muchos problemas, lo que hace que el código sea demasiado complejo. Da miedo cómo las personas usan en exceso el STL y creo que esa es una de las causas por las que tantos (incluido yo mismo) se abstienen de usarlo. Como un ejemplo que vi hace poco, donde la pregunta era cómo obtener el mayor número de 3 números, una de las respuestas fue empujarlos a un std :: vector y luego std: ordenarlo. Eso definitivamente obliga a una solución innecesaria a un problema muy simple.
Simon
22
@Simon: con el debido respeto, el último ejemplo es un signo de falta de idea extrema, y ​​no tiene nada que ver con STL ... esa persona haría lo mismo en cualquier otro idioma con listas que se puedan ordenar. Es su pensamiento lo que está roto.
ggambett
@EdRopple intenta implementar un analizador STL para archivos de imagen PPM (menos de 100 líneas de código en total si solo apunta a P6 o P3). La mitad del código resultante es solo para omitir las líneas de comentarios porque STL no proporciona algo comoif(stream.nextCharacter() == '#') stream.skipLine();
GameDeveloper
@DarioOO No conozco ese formato de archivo, pero para eso están los adaptadores de flujo y los filtros. Escribí ese comentario hace cinco años, mente (¡y ocasionalmente sigue volviendo!), Pero en estos días escribo sobre cualquier cosa que no sea súper, súper crítica en un estilo funcional y basado en transformaciones y problemas como el que tú Estamos describiendo la caída del problema. Realmente no me importa mucho el recuento de líneas (y la OMI tampoco debería), me importa la corrección de la implementación, luego la claridad, el rendimiento y luego cosas como la longitud del código.
Ed Ropple el
63

Diría que, desde la parte superior de mi cabeza, es una mejor idea usar el STL a menos que sepa exactamente por qué no quiere usarlo.

Esto es lo que pasa con el STL: está desarrollado por personas que son más inteligentes que usted. Eso no pretende ser ofensivo ni nada, es solo que el STL es desarrollado por personas cuyo trabajo es realmente construir el STL. Será casi tan rápido como la plataforma lo permita y, en general, será mucho más robusto que una solución casera (y esto debería ser una gran preocupación si no más que preocuparse por la velocidad bruta, porque su juego necesita robustez un poco más de lo que necesita velocidad; este último no tiene sentido sin el primero).

Las quejas de que la STL impone una "visión estrecha del mundo" me parecen un poco tontas. Son contenedores. Tienen un conjunto limitado de operaciones porque los contenedores tienen conjuntos limitados de operaciones. ¿Qué haces que no concuerda con esto?

Ed Ropple
fuente
44
No creo que nadie deba justificar por qué no deberían usar STL. Tampoco esté de acuerdo con todo el argumento 'úselo porque son más inteligentes que usted' STL ha sido diseñado en torno a un punto de vista específico de un dominio del problema, no sólo los contenedores, es decir, algoritmos, asignadores, iteradores, rasgos etc Eso es justo lo suficiente, pero no es la única manera de mirar que dominio del problema
zebrabox
2
¿Prefieres un código casero que un código probado y robusto? El dominio del problema no es tan diferente de un proyecto a otro (aparte de quizás proyectos integrados, ¡incluso las consolas tienen implementaciones STL decentes en estos días!). Independientemente del juego, su problema no es tan diferente, y si está haciendo algo que tiene la intención de enviar, tiene la responsabilidad implícita de escribir código robusto. ¿Volver a implementar la rueda va a conducir a una mejor robustez y flexibilidad? Me inclino hacia el "no". Que no sea la "única forma" no implica que no sea generalmente superior.
Ed Ropple
20
Diría que gamedev se trata de hacer juegos , pero está bien. Si sus suposiciones son tan pobres que se le perfora en ese tipo de asignación de recursos, entonces, sí, debe retroceder y reevaluarlas. Pero puede crear aplicaciones increíblemente rápidas que también utilicen el STL, y, ciertamente, cualquier otra implementación, cuando realmente sepa lo que está haciendo . Aprender lo que estás haciendo> rechazar la carga del STL. Nadie dijo que el STL es siempre la mejor respuesta. Lo que estoy diciendo es que si no puede explicar por qué no es el mejor curso , debería usar el STL.
Ed Ropple
11
No creo que sea provocativo en absoluto: está redactado de manera que quede grabado en la memoria de alguien, pero es una postura extremadamente conservadora y directa. En resumen: las personas que desarrollan el STL tienen más conocimiento y están mejor equipadas que alguien que descubre que tienen que hacer esta pregunta. Si tiene que preguntarle a alguien más si el STL es apropiado o no, seguramente le faltará el conocimiento específico del dominio para preparar adecuadamente una solución casera.
Ed Ropple
44
"Será casi tan rápido como la plataforma lo permita". Esta es una falsedad definitiva, ya que muchos proveedores de compiladores no pueden molestarse en reescribir el STL para que realmente exprima el máximo rendimiento de la arquitectura particular. STL no tiene garantía alguna sobre las características de rendimiento, excepto para grandes O. O, sin embargo, podría ser tan eficiente o ineficiente como el proveedor del compilador quiere lograr.
Kaj
35

He visto muy pocas razones para no usar el STL para juegos.

Para los problemas de asignación de memoria, muchas personas no lo saben, pero puede escribir asignadores personalizados para sus clases de contenedor STL. Los asignadores son básicamente clases de políticas que pasa a sus plantillas para determinar cómo se realizan las asignaciones. Con estos, generalmente puede solucionar cualquier problema de memoria que sea problemático en su plataforma de elección.

Por supuesto, si está utilizando el STL y está haciendo cosas tontas como mapas de cadenas a tipos grandes, sin puntero, entonces tiene mayores problemas en su mano.

Tétrada
fuente
En realidad, el uso de tipos grandes sin puntero en el mapa es un buen caso de uso porque los mapas stdlib tienen el requisito de no invalidar iteradores que obligan a la implementación a usar punteros y elementos mapeados asignados individualmente. La mejor solución para los juegos es usar google::sparse_mapo escribir el propio.
v.oddou
¿Por qué no mapa denso?
GameDeveloper
23

El STL predeterminado tiene un buen número de problemas que dificultan su uso con juegos, especialmente cuando se trata de la alineación de la memoria.

Una variante personalizada como EA STL está especialmente diseñada para juegos y puede obtener un rendimiento de memoria y una usabilidad de consola mucho mejores. Se convirtió en código abierto en 2016, bajo una cláusula BSD-3, con un repositorio en GitHub .

Ben Zeigler
fuente
19
Los problemas con el uso de la memoria y los juegos de STL generalmente se pueden resolver con clases de asignadores personalizados. De hecho, en mi trabajo anterior, nuestra clase de vector "personalizada" era solo una envoltura delgada std::vectorque anulaba el asignador predeterminado.
Blair Holloway
1
@Blair Holloway: "Los asignadores personalizados están basados ​​en clases, no en instancias. Se requieren asignadores para construir y destruir objetos, así como para asignarlos. Esto obliga a mezclar dos conceptos separados: asignación y construcción. Estos son solo algunos de los problemas con stl-allocators, desafortunadamente ". El EA STL da varias razones más válidas por las cuales los asignadores de STD son malos. No es solo "si pueden o no ser anulados".
Simon
@ Simon: No argumentaré que el sistema de asignación de STL es perfecto, porque no lo es. Nos llevó mucho tiempo encontrar una solución que funcionara. Lo que digo es que, en algunos casos, es posible obtener una solución viable y amigable para los juegos usando STL y un poco de trabajo con asignadores personalizados.
Blair Holloway
@Simon - Para elaborar: aunque el STL puede ser engorroso, es un código muy bien probado y libre de errores; si puede usarlo, ahorrará horas de trabajo al tener que depurar una solución personalizada. Mi trabajo actual evita el STL a favor de los asignadores elaborados en casa, y he tenido que pasar tiempo depurando y refactorizando parte de ese código, porque no tiene el mismo nivel de madurez que el STL.
Blair Holloway
1
@ Simon: Llego un poco tarde a la fiesta aquí, pero tengo curiosidad por darme un ejemplo específico de lo que quieres decir con eso. ¿Cuál es un buen ejemplo de resolver un problema específico de una manera que el STL es demasiado general para resolverlo de manera eficiente?
Sorteo el
21

Esto es lo que Mike Acton (Director de motores en Insomniac Games of Spyro the Dragon, Ratchet & Clank y Resistance) tuvo que decir sobre esto cuando se le preguntó aquí . Tenga en cuenta que se le preguntó sobre STL y Boost en general en relación con el uso en el desarrollo del juego.

STL / Boost, ¿pertenece a gamedev? Si solo partes de él, ¿cuáles?

Estás preguntando acerca de dos cosas diferentes aquí, ¿verdad? STL y Boost, por separado. Pero realmente, mi respuesta es la misma: no hay nada de malo en ninguno de los dos, pero desaconsejo su uso. El uso de cualquiera alienta a las personas a adaptar una solución a un problema en lugar de encontrar una solución a un problema. La solución siempre debe ser apropiada para los datos disponibles y las restricciones del hardware, etc. Tanto STL como Boost tienen una visión extremadamente estrecha del "mundo" y su uso apropiado es limitado. Realmente, los desaliento porque conducen a los programadores por la dirección equivocada de inmediato, a menudo digo que si sientes que necesitas cualquiera de los dos, probablemente no entiendas realmente el problema.

También he notado que la mayoría de los desarrolladores de juegos profesionales se esfuerzan más hacia C que C ++.

Fotograma clave
fuente
18
No estoy de acuerdo en esforzarme más por C. La gran mayoría de los desarrolladores de juegos, así como los escritores de SDK, usan C ++. De hecho, el último usuario importante de C era id e incluso Carmack ha pasado a C ++ ahora ...
Goz
82
El comentario del Sr. Acton parece incompleto. En términos generales, el STL es una buena opción para esos problemas. Si está tratando de hacer algo de tal manera que el enfoque STL parezca "incorrecto", probablemente sea una muy buena idea reevaluar su enfoque y ver si realmente lo está haciendo de manera inteligente. En mi experiencia, la mayoría de las veces, probablemente no lo seas. (Es mucho más inteligente, en mi opinión, resolver un problema entendiéndolo fuertemente en el contexto de sus herramientas que tirar sus herramientas solo para rehacerlo desde cero.)
Ed Ropple
50
Mi experiencia con STL ha sido casi opuesta. Es eficiente y ahorra tiempo. Si siente la necesidad de rodar su propia biblioteca de plantillas o biblioteca de contenedores, entonces está bien. Pero no pretendas que el STL (o impulso, para el caso) es malo. He usado STL ampliamente en juegos comerciales para iPhone, Nintendo DS, Wii, PC, Mac y Xbox. Cada vez que me veo obligado a usar la biblioteca "mejor" de otra persona, la encuentro faltante y con errores.
Sorteo del
55
Funciona tan bien en el DS como en cualquier otra plataforma en la que lo haya usado. Usé STL en todo el código UI y AI. El juego fue ds.ign.com/articles/832/832147p1.html . Estaba trabajando en un pequeño estudio que formaba parte de Amaze, que formaba parte de la Fundación 9.
Sorteo
77
Mike tiene que ver con los datos. Mirar los datos sugiere el mejor método para transformar los datos. Aplícalo a gran escala y tienes programación. En este contexto, su crítica tiene mucho sentido. STL (y los patrones de diseño) sugieren que, en lugar de examinar los datos para encontrar una solución, examinamos las soluciones en nuestra bolsa de trucos para encontrar una que funcione con los datos. No pretendo hablar por Mike, pero creo que sugeriría que esta forma de abordar el problema es al revés y puede conducir a soluciones ineficientes o infladas.
Dan Olson
19

Si se encuentra reescribiendo algo que ya existe en el STL, por cualquier motivo, deténgase . Usa el STL.

El STL se ha optimizado durante años de análisis y tiempo, y es una apuesta segura que probablemente no va a escribir algo que sea más eficiente. Eso no quiere decir que deba usar STL donde una solución más simple sea posible (es decir, use una matriz cuando tenga una cantidad conocida de cosas, no una lista stl ::), pero si está escribiendo su propia implementación de un mapa ( la estructura de datos básica, no un mapa mundial del juego), lo estás haciendo mal.

Ricket
fuente
77
map <> casi nunca es lo que quieres usar para nada de memoria o CPU eficiente en el contexto de un juego. hash_map <> es casi siempre una mejor opción, aunque el rendimiento de hash_map difiere mucho del proveedor. Si está creando un juego que sea para consola o para funciones de juego escalable en red, STL puede ser demasiado lento o hinchado para sus propósitos.
Ben Zeigler
3
unordered_map <> ahora está ampliamente disponible y tiene requisitos de rendimiento extremadamente estrictos en el borrador TR1 actual. (Para el punto de especificación excesiva Creo - que incluso prohíbe hash abierto, y aunque eso es por lo general más lento, no creo que debería ser pura y simple prohibido por la norma.)
55
El STL ofrece algoritmos y contenedores. Nunca hay una razón para no usar la versión stl de un algoritmo. Por ejemplo, std::sortgeneralmente usa introsort debajo, increíblemente rápido y lo suficientemente complejo como para que no quieras hacerlo tú mismo.
deft_code
la verdad es unordered_mapque C ++ 11 o boost son demasiado lentos, lo que quieres es un mapa de hash de dirección abierta, como google :: sparse_map o el tuyo.
v.oddou
16

¿Es STL una buena opción para los juegos? Seguro. Los juegos son piezas complejas de software, el STL proporciona características que ayudan a gestionar la complejidad, por lo que es bueno.

¿Es un buen ajuste para su plataforma? No necesariamente. Si está escribiendo para una consola, debe tener mucho cuidado con el uso de memoria y caché. El STL no hace esto muy fácil.

Creo que con demasiada frecuencia confundimos los "juegos" con los "juegos en tiempo real de alto rendimiento que se ejecutan en hardware integrado o a medida", pero es importante hacer una distinción. Si está escribiendo un juego de Windows que no intenta ejecutarse en pantalla completa a una velocidad constante de 60 fps, entonces no hay razón para evitar las herramientas que le brinda la biblioteca estándar.

Kylotan
fuente
10

Sé que es muy tarde para la fiesta, pero el tiempo cambia y las respuestas permanecen. C ++ 11 tiene cambios bastante radicales, muchos de los cuales son para aumentar el rendimiento de C ++ y la biblioteca estándar. Parece que aquellos que no usan STL o Boost, tienden a no mantenerse al día con los nuevos estándares tampoco, dejando que las soluciones caseras no tengan mejoras importantes, por supuesto, este no es siempre el caso.

He usado STL en todos los proyectos desde mediados de los 90 hasta hoy, con la excepción de un corto tiempo en EA. Creo que el lado anti STL tenía algunas razones marginalmente racionales para no usarlo. Esos se han ido en gran medida. Los asignadores personalizados son una solución, el uso de la reserva es otra, y no pasar cosas por valor es un tercero, pero estos son bastante simples y cualquier programador debería saberlo. Sin embargo, lo más importante es el uso de algoritmos. Los escritores de compiladores saben exactamente lo que hace for_each () y pueden optimizar el código. Eso no puede ocurrir con un bucle de inicio. for_each () en un objeto const es aún mejor. Microsoft optimiza para cada uno de muchas maneras, incluida la serialización. También tienen la biblioteca AMP que tiene parallel_for_each (). Si tiene la oportunidad, hable con los ingenieros del compilador sobre esto. Los compiladores de consola van a optimizar lo que se usa, así que ' es un problema de huevo y gallina. Microsoft se está volviendo muy pesado con C ++ 11 y el próximo XBox no será diferente. No tengo idea sobre PS4, todavía no tenemos una.

Los asignadores personalizados son una forma de manejar el problema de memoria, pero otra opción (a menudo pasada por alto) es usar new y delete basado en clases. Se pueden obtener enormes aumentos de rendimiento de esta manera.

La noción de que Boost y STL tienen una visión estrecha de la resolución de problemas es pura locura. Estoy sorprendido de cuántas cosas en STL y Boost se pueden personalizar a través de rasgos y políticas. Busque una cadena independiente de mayúsculas y minúsculas como ejemplo.

Con respecto a los tiempos de enlace largos y la hinchazón de código, la nueva plantilla externa debería ayudar con esto. En general, encuentro que los tiempos de compilación largos provienen del exceso de acoplamiento y el mal uso de pch.

La razón más convincente para usar STL en lugar de homepun es que hay millones de personas que pueden ayudarlo con STL. Como siempre, no optimices prematuramente y prueba, prueba, prueba.

Tavison
fuente
ideas interesantes ¿Qué quieres decir con " usar clase basada en nuevo y eliminar "? ¿Quieres decir, acelerar un proceso utilizando objetos que ya están en el montón?
johnbakers
9

Este es un tema candente en el desarrollo de juegos. Yo personalmente no lo recomiendo, excepto quizás por EASTL como se mencionó anteriormente. Tengo dos problemas principales con STL (técnicamente "The C ++ Standard Library", ya que STL ya no es el nombre) en los juegos. 1) La asignación de memoria dinámica a menudo desperdicia mucho tiempo de ejecución en los juegos cuando se usa STL. 2) El uso de STL fomenta un enfoque de matriz de estructuras para la arquitectura del juego, mientras que un enfoque de estructura de matrices es mucho más amigable con la caché.

Terrance Cohen
fuente
Como se mencionó en otra parte, puede proporcionar asignadores personalizados para las clases de contenedor; estos podrían usar listas de favoritos si lo desea (matrices preasignadas). La matriz de estructuras vs estructura de matrices depende mucho de lo que intente hacer: no existe una regla estricta sobre cuál es mejor.
Skizz
Aprecio tu punto de que es importante entender bien el problema que estás resolviendo. Pero con respeto, sigo pensando que no estoy de acuerdo con tu conclusión. Cada problema tiene patrones de uso que no pueden expresarse en asignadores de STL personalizados, pero pueden aprovecharse fácilmente en un contenedor personalizado, como un asignador de bloque fijo implementado con una matriz plana. Y la aplicación de una transformación fija sobre una matriz de tipos homogéneos muy probablemente dará como resultado una coherencia de caché mucho mejor que iterar sobre un vector de tipos polimórficos e invocar métodos virtuales.
Terrance Cohen
5

Depende. ¿Qué tan grande es el proyecto, qué plataforma (s) y cuál es la línea de tiempo?

Si está trabajando en un proyecto grande, en plataformas con recursos limitados, con una línea de tiempo y un presupuesto significativos, entonces puede ahorrarse muchos problemas al evitar el infierno inevitable que se verá en una base de código de línea de medio millón que es lleno de STL, no puede mantener una velocidad de fotogramas por encima de 30, come suficiente RAM para adaptarse a varios activos más y tarda 2 horas en construirse.

Sin embargo, en otras situaciones, STL e incluso Boost pueden ser muy útiles cuando se aplican adecuadamente. He trabajado en títulos que usaban una selección de STL / Boost, y era un sueño absoluto para codificar: ¡menos errores / fugas y un código fácil de mantener significa más tiempo para codificar nuevas funciones divertidas! Especialmente para proyectos de pasatiempo, es una gran victoria en el departamento de motivación.

¡Sepa cuándo cambiar el rendimiento por conveniencia!

Jason Kozak
fuente
1
"Sepa cuándo cambiar el rendimiento por conveniencia". Si. Esta oración sola es una respuesta tan buena como cualquier otra. Averigua qué necesitas lograr con tu juego, consulta a tus compañeros y decide si STL te ayudará a llegar allí o te obstaculizará. Diría que si no estás buscando establecer el estándar para gráficos y rendimiento de próxima generación con tu juego, STL probablemente te ayudará.
gkimsey
4

En mi humilde opinión, diría que es una buena opción ya que STL ya funciona bien y está optimizado para las tareas para las que está hecho. Además, estás trabajando en un juego, así que usa las herramientas que tienes a mano para que tu vida sea más fácil y tu código sea menos propenso a errores.

¿Por qué molestarse en reinventar la rueda cuando puede estar trabajando en otra cosa como la IA del juego, la experiencia del usuario o mejor aún? prueba y depuración?

pctroll
fuente
2
En la práctica, hacia el final de un proyecto, el desempeño tiende a ser un problema crítico. Si usa STL, tiene muy pocas oportunidades de optimización porque toma sus aplicaciones específicas y las resuelve de manera general. Resolver casos específicos de una manera específica (y sin asignación de memoria dinámica) es casi siempre un rendimiento superior.
Terrance Cohen
2
Pero si no desea la asignación dinámica de memoria, entonces no debería estar usando el STL. Ese es una especie de punto. Su propio código no será mejor, y ciertamente podría ser bastante peor. La decisión de diseño de hacer un mal uso del STL es el problema aquí, no el STL, sus capacidades o sus características de rendimiento. Estás atacando la parte equivocada del problema.
Ed Ropple
4

STL está absolutamente bien para usar en juegos, siempre y cuando lo entiendas bien. Nuestro motor hace un uso bastante extenso y nunca ha sido un problema. No tengo ninguna experiencia con el desarrollo de consolas, lo que puede ser una historia completamente diferente, pero es compatible con todas las plataformas de PC (Windows / Mac / Linux).

Lo más importante es comprender cuáles son las fortalezas y debilidades de cada tipo de contenedor y elegir el contenedor correcto para el trabajo que está haciendo.

Jason Morales
fuente
4

Mi antiguo empleador pasó de usar un conjunto robusto de clases de contenedores personalizados a STL. Los tiempos de construcción aumentaron y la facilidad de depuración disminuyó, ambos de manera bastante significativa. Si hubiéramos estado comenzando desde cero, STL (quizás mejor usado) probablemente habría tenido sentido, pero nunca me quedó claro que ganamos algo al cambiar a STL que justificara arrojar código de trabajo, rápido y depurable.

Para mis proyectos personales, si STL encaja o no depende del proyecto. Si estoy tratando de hacer un trabajo optimizado de acceso a memoria y caché basado en datos al estilo Mike Acton, al menos pensaré en rodar mis propias estructuras de datos personalizadas. Si estoy creando prototipos de algunos algoritmos o juegos y no me importa el rendimiento, la escalabilidad, la plataforma de destino, etc., automáticamente tomaré STL.

Tom Hudson
fuente
4

Mis 2 centavos en esto es que el STL funciona bien. He estado desarrollando un motor de juego 3D (no de calidad AAA, pero lo suficientemente avanzado: tipos de entidades con secuencias de comandos, renderizador diferido, física de Bullet integrada) para PC y aún no he visto que los contenedores se conviertan en el principal cuello de botella. El uso incorrecto de la API 3D y los algoritmos deficientes han sido los mejores objetivos (¡determinados por el perfil!) Cada vez que entro e intento obtener un poco más de rendimiento.

Branan
fuente
3

He creado juegos con STL y me gusta, y parece funcionar bien.

Kevin Laity
fuente
3

¡Buena pregunta! Una pregunta más específica es cuáles son algunos requisitos comunes que tendría un juego que no se pueden cumplir con STL y Boost.

En mi experiencia, las limitadas limitaciones de memoria del hardware de la consola hacen que cualquier tipo de contenedor de tamaño dinámico sea una mala idea, independientemente de cuán inteligente sea su asignador personalizado. Los contenedores que no tienen límites deliberados alientan a los programadores a escribir código que no limite los límites de sus conjuntos de datos. Dependiendo de innumerables variables que son difíciles de rastrear, puede exceder sus limitaciones de memoria. Tengo el presentimiento de que esta es una de las principales causas de inestabilidad en los juegos modernos.

Además, el uso excesivo de plantillas puede conducir a tiempos de compilación muy largos en una base de código grande, y aumentará el tamaño de su ejecutable para que ya no encaje en la caché de, por ejemplo, un núcleo auxiliar en una ps3.

Sin embargo, para el desarrollo solo para PC, creo que STL y Boost son muy buenos. Si bien las soluciones de casos generales no siempre son ideales, a menudo son lo suficientemente buenas. Su primera solución a un problema casi nunca es ideal, y usted mejora o reemplaza las deficiencias hasta que sea lo suficientemente bueno.

Evan Rogers
fuente
2

El STL es un buen ajuste para su juego si el STL es un buen ajuste para su juego.

Al igual que con todas las elecciones de tecnología realizadas durante el desarrollo, debe sopesar los pros y los contras: ¿rodar mi propia biblioteca me dará un uso de memoria, rendimiento y productividad más beneficiosos que simplemente usar el STL? Posiblemente; aunque es igual de fácil crear una vectorimplementación que use más memoria, sea más lenta y requiera grandes cantidades de mantenimiento para seguir funcionando en comparación con lo que ya existe.

Las personas no deben evitar usar el STL en sus juegos porque otras personas evitan usar el STL en los juegos; deben evitar usarlo si han sopesado todas sus opciones y realmente creen que otra implementación mejorará la calidad de su producto.

Blair Holloway
fuente
2
Estoy 100% de acuerdo con la última parte de tu comentario, pero iría aún más lejos: si puedes demostrar de manera concluyente por qué el STL no es una buena opción, no uses el STL. De lo contrario, hazlo. El culto a la carga (todo, desde "¡oh, los desarrolladores de juegos usan C ++!" Hasta "¡oh, los desarrolladores de juegos no usan el STL!") No es saludable. Sin embargo, me gustaría tener un pequeño problema con su segundo párrafo: es bastante improbable que las personas que todavía son lo suficientemente ingenuas como para pensar que reimplementar el STL sea una buena idea construyan una mejor vectorque la gente de STL. Para cuando puedas hacerlo, ¡ya no crees que necesites hacerlo! :-)
Ed Ropple
2

Como con la mayoría de las preguntas, la respuesta nunca es "sí o no", blanco o negro. STL es una buena opción para algunos problemas, usarlo para esos problemas debería estar bien. Es un error suponer que es inútil, pero también es un error suponer que es apropiado usarlo en cada situación.

El mayor problema a tener en cuenta cuando se usa STL en el desarrollo del juego es la asignación de memoria. Los asignadores predeterminados de STL no parecen encajar bien en las estrategias de asignación preferidas para el desarrollo del juego. Por supuesto, se pueden usar asignadores personalizados, pero esto hace que la idea sea menos atractiva si está considerando agregar STL a una base de código que no sea STL.

Agregue a esto que si su base de código no es STL, es posible que no tenga a nadie lo suficientemente familiarizado con STL o los conceptos de plantilla para implementar los asignadores personalizados correctamente.

Dan Olson
fuente
2

Creo que esta discusión se puede resumir de la siguiente manera:

código específico de aplicación mediocremente escrito <código de propósito general bien escrito <código específico de aplicación bien escrito

Cualquiera cuya solución local caiga en la categoría 3 seguramente sabe la respuesta a la pregunta original para su problema particular. El STL cae en la categoría 2. Así que para alguien que tiene que hacer la pregunta, "debería yo utilizar la STL", la respuesta es probablemente sí.


fuente
2

STL está bien para usar en una PC, ya que su avanzado sistema de memoria virtual hace que la necesidad de una asignación cuidadosa de la memoria sea un poco menos crucial (aunque aún se debe tener mucho cuidado). En una consola, con recursos de memoria virtual limitados o inexistentes y costos de pérdida de memoria caché exorbitantes, probablemente esté mejor escribiendo estructuras de datos personalizadas que tengan patrones de asignación de memoria predecibles y / o limitados. (Y ciertamente tampoco te equivocarás haciendo lo mismo en un proyecto de juego de PC).

Mustafa Ekici
fuente
1

Creo que esta pregunta es realmente una pregunta no formulada más grande: ¿debería usar X en mi Y ? Y la única forma de responder realmente es probarlo usted mismo. Por cada persona que encuentre que diga que X funciona muy bien, encontrará a alguien que diga que es horrible. Y ambos tienen razón: para su proyecto.

Lo mejor del software, a diferencia de la mayoría de las otras disciplinas, es que siempre puedes cambiar las cosas más adelante si descubres que no funciona de la manera que te gustaría. ¿Descubres más tarde que STL no te funciona en este proyecto? Sácalo, pon algo más en su lugar. ¿No te gusta cómo dividiste los deberes entre tus objetos? Refactorizador ¿No te gusta que hayas usado objetos? Reemplácelos con métodos C rectos. ¿No le gusta que todo se almacene en estructuras y métodos para manipularlos? Reemplácelos con objetos C ++.

Dennis Munsie
fuente
1
Si bien tienes razón, puede haber una gran penalización por refactorizar; por lo tanto, tomar una decisión informada por adelantado en lugar de una arbitraria le ahorrará tiempo a largo plazo.
Alan
1

Yo digo no a la STL. Mi razón es bastante simple:

  1. No necesitas el STL para escribir juegos. Ni siquiera los grandes.
  2. STL aumenta dramáticamente su tiempo de compilación.
  3. El tiempo de compilación grande conduce a menos iteraciones sobre su desarrollo.

Considero que el recuento de iteraciones es de la mayor importancia, por lo que me mantengo alejado del STL y de cualquier otra técnica de desarrollo que ralentice las iteraciones (como la arquitectura por el bien o los lenguajes de script que deben compilarse).

Las iteraciones costosas conducen a enormes equipos de desarrollo de personas que intentan hacer las cosas con muy poca realidad. Lo he visto y escuchado, y uno de los culpables parece ser los tiempos de compilación para bibliotecas de plantillas.

Richard Fabian
fuente
1
Estoy de acuerdo con los tiempos de compilación. Cualquier tiempo de compilación significativo duplica la cantidad de trabajo perdido; por ejemplo, si la compilación dura 5 minutos, pasará 10 minutos tomando café cada vez. ;)
Ipsquiggle
Si bien veo ambos lados de este argumento, debo decir que estoy totalmente de acuerdo con tu argumento, Richard. +1.
Ingeniero