¿Por qué los desarrolladores de juegos de C ++ no usan la biblioteca de impulso? [cerrado]

Por lo tanto, si pasa algún tiempo viendo / respondiendo preguntas en Stack Overflow bajo la etiqueta C ++, notará rápidamente que casi todos usan la biblioteca de impulso ; algunos incluso dirían que si no lo está utilizando, no está escribiendo "C ++ real" (no estoy de acuerdo, pero ese no es el punto).

Pero luego está la industria de los juegos, que es conocida por usar C ++ y no usar boost. No puedo evitar preguntarme por qué es eso. No me importa usar boost porque escribo juegos (ahora) como pasatiempo, y parte de ese pasatiempo es implementar lo que necesito cuando puedo y usar bibliotecas disponibles cuando no puedo. Pero ese soy solo yo.

¿Por qué los desarrolladores de juegos, en general, no usan la biblioteca de impulso? ¿Se trata de problemas de rendimiento o memoria? ¿Estilo? ¿Algo más?

Estaba a punto de preguntar esto en el desbordamiento de la pila, pero pensé que la pregunta es mejor aquí.

EDITAR:

Me doy cuenta de que no puedo hablar por todos los programadores de juegos y no he visto todos los proyectos de juegos, así que no puedo decir que los desarrolladores de juegos nunca usen boost; Esta es simplemente mi experiencia.

Permítame editar mi pregunta para preguntar también, si usa boost, ¿por qué eligió usarlo?

Algunos desarrolladores lo hacen, otros no (en juegos y en otros lugares). Depende de cuáles son las necesidades / requisitos de esos desarrolladores y qué tecnología existente tienen que aprovechar.

Biblioteca estándar de C ++ 's a menudo se da el mismo tratamiento, y la gente a menudo se preguntan lo mismo que usted está preguntando acerca de que , también. La mayoría de las razones son similares, por ejemplo:

• Un desarrollador ya puede tener una biblioteca interna de funcionalidades que proporciona los mismos servicios que proporciona la biblioteca estándar o Boost. Tales bibliotecas internas a menudo se escribieron hace mucho tiempo, cuando el soporte de implementación para la biblioteca estándar era débil y Boost era básicamente inexistente, por lo que tenían que escribirse más o menos . En este escenario, generalmente no vale la pena hacer una transición lejos de la funcionalidad interna: sería un gran esfuerzo de transferencia que desestabilizaría mucho código y casi no proporcionaría ningún beneficio.

• Un desarrollador puede estar trabajando en plataformas donde el soporte del compilador para las técnicas avanzadas de C ++ apalancadas por Boost no está bien soportado, de modo que el código de Boost no se compila en absoluto o funciona bastante mal. Esto también se aplica a la biblioteca estándar, aunque mucho menos en estos días.

• Boost y la biblioteca estándar del lenguaje son de uso general, y aunque eso es bueno y bueno para la mayoría de las aplicaciones, a veces un desarrollador tiene necesidades específicas que pueden ser mejor atendidas por contenedores más especializados.

Creo que lo anterior son dos razones razonables, aunque ciertamente hay otras. Sin embargo, debe tener cuidado porque hay muchas razones para evitar Boost, las bibliotecas estándar o lo que sea que se reduzca al síndrome de "no inventado aquí", lo que puede ser una indicación de que la razón no está muy bien basada en realidades prácticas.

También recuerde que las necesidades de un estudio de gran tamaño suelen ser muy diferentes de las necesidades de un desarrollador individual. Por ejemplo, un desarrollador individual probablemente tenga menos código heredado flotando para mantener y, por lo tanto, tal vez la transferencia desde una versión local de Boost o la funcionalidad estándar de la biblioteca no será tan importante y evitará que el desarrollador tenga que mantener ese código tan extenso en el futuro, invalidando así mi primer punto de viñeta.

Al final, se trata de evaluar sus requisitos y la inversión de tiempo contra su objetivo deseado y determinar qué opción satisface mejor sus necesidades. Los desarrolladores que no usan Boost o la biblioteca estándar generalmente lo han hecho y llegaron a esa conclusión, tal vez tú también, y tal vez no.

Editar Volviendo a esta pregunta después de unos años
Después de seguir usando más y más bibliotecas de impulso, pensé en actualizar esta pregunta para dar un caso sólido de por qué debería usar impulso cuando la descripción del producto coincide con la funcionalidad deseada. Esto convencerá incluso a los que no lo dicen. Descargue openSSL, intente crear una aplicación de cliente y servidor con él. Ahora intenta hacer que funcione en todas las plataformas. Luego, descargue y use boost :: asio :: ssl para hacer la misma aplicación. Si no está convencido de que impulsar es el lugar correcto para buscar código multiplataforma limpio, bien optimizado, revisado por pares, este simple ejercicio lo convertirá.

Tl; versión dr:

En mi opinión, no ves un montón de empresas de desarrollo independientes o pequeñas o medianas que usan boost porque es una bestia salvaje masiva y poderosa que no es fácil de domesticar y básicamente estás solo cuando intentas aprender cómo para usarlo La documentación falta de varias maneras (ver versión larga) y "la comunidad" en torno al proyecto parece estar ausente, dispersa o inactiva (en comparación con otros proyectos).

Versión muy larga:

me doy cuenta de que ya hay una respuesta aceptada, pero como alguien que realmente usa el impulso en casi todos los proyectos que hago, pensé en publicar una respuesta.

Recuerdo la primera vez que busqué un impulso y, sinceramente, no tenía una idea de lo que estaba sucediendo. Boost no está muy bien documentado en absoluto. Es posible que la gente no esté de acuerdo conmigo en que estoy seguro porque hay toneladas de fragmentos de código de ejemplo y comentarios y demás, pero todo es muy frío y vago, así como difícil de navegar.

También parece difícil encontrar un lugar donde sienta que ha encontrado "la comunidad" en torno al proyecto. De hecho, la comunidad parece inexistente o nómada. Desafortunadamente, incluso su lista de correo ha sido controlada por tantos sitios de sanguijuelas que puedes ir por este agujero de conejo siempre volviendo a donde comenzaste.

Estos dos factores hacen que aprender a usar las bibliotecas de impulso sea una tarea bastante desalentadora. Incluso si los tecnicismos del uso de boost no son excesivamente complejos, es un conjunto masivo de bibliotecas y lo mira cuando todo lo que está armado es con algunos fragmentos de código y partes dispersas de la lista de correo desde los rincones más oscuros de Internet ... Bueno, ya captas la idea.

Empecé a jugar con el impulso alrededor de la versión 1.45 y solo ahora en la versión 1.52 / 1.53 me siento lo suficientemente cómodo como para usarlo en la producción. Hay tantas cosas a las que acostumbrarse y recordar, incluso cosas simples como la forma en que ha configurado boost y recordar esa configuración, porque la forma en que se construyen y funcionan las bibliotecas puede variar enormemente según sus preferencias en el momento de la compilación debido a las cosas personalizables son.

Sin embargo , no se equivoque , una vez que puede empujar impulso, ha ganado un arma poderosa para construir rápidamente programas sólidos y multiplataforma. Solo toma boost::asiopor ejemplo. Puede escribir un servidor web asíncrono multiplataforma inmensamente potente, escalable y sólido como una roca en solo un par de cientos de líneas. He escrito varios clientes, servidores, servidores proxy, etc. a lo largo de los años con solo unos cientos de líneas de código cada uno que aún no me han fallado, y pueden portarlos de plataforma en plataforma en minutos.

Como otros han señalado, las compañías más grandes generalmente están atrapadas con cosas heredadas o les gusta rodar las suyas, lo que entiendo completamente. También existe esta cosa realmente tonta de la que he oído hablar y que encontré donde los líderes de desarrollo y / o gerentes de proyecto prohíben el uso de impulso porque es "demasiado grande". Supongo que creen que el impulso es 1 biblioteca única o que nunca han oído hablar de BCP .

En cuanto a POR QUÉ elijo usar boost

Yo diría que lo uso porque, como usted implica en su pregunta, es "la" biblioteca de C ++. Boost es visto en el mundo de C ++ como la navaja suiza de las cosas que eventualmente necesitarás usar. Entonces, la idea es que si hay una necesidad, debe haber una versión portátil de alto rendimiento en impulso. Las grandes empresas contribuyen a impulsar , las personas muy educadas con currículums impresionantes contribuyen y lo mantienen , y cuando se desarrolla un nuevo estándar de C ++, las personas generalmente buscan impulsar para ver qué partes del mismo deberían convertirse en C ++ estandarizado por ISO.

Entonces, si necesito agregar alguna funcionalidad para la que probablemente haya una biblioteca existente, el primer lugar que buscaré es impulsar solo porque estoy bastante seguro al apostar que está bastante bien optimizado, es portátil, será compatible y mantenido para mucho tiempo y se encontrarán y solucionarán errores. En el mundo del código abierto, esas cualidades pueden ser muy difíciles de conseguir.

Usamos un poco de Boost en nuestro antiguo lugar de trabajo. Las principales razones para evitarlo y limitar su uso fueron:

• tiempos de compilación: algunos de ellos son muy lentos para compilar, y terminas siendo reacio a tener un impulso #incluye en cualquiera de tus encabezados
• complejidad: no es bien conocida por la mayoría de los desarrolladores de juegos y, por lo tanto, genera código ilegible
• rendimiento: algunos de los conceptos funcionan lentamente de forma predeterminada, por ejemplo. shared_ptr

Lo mismo se dice (¿se dice?) Para el STL "más estándar". Este artículo habla sobre EASTL, una reescritura interna de (partes de) STL de Electronic Arts para satisfacer las necesidades de desarrollo de juegos que son bastante diferentes a las del desarrollo de aplicaciones "más genéricas".

¡Entonces, tal vez, alguien en algún lugar está reescribiendo (partes de) impulso para satisfacer sus necesidades en el desarrollo del juego!

¿Quién dice que no usan impulso? He conocido uno o dos motores C ++ que han usado boost. Nunca he trabajado directamente con ellos; pero, eso es principalmente porque mi experiencia radica en Unreal.

En cuanto a las razones que he encontrado para no usar boost, y estas son subjetivas:

• Nos gusta rodar nuestras propias estructuras de datos específicas para las plataformas en las que estamos implementando
• Nos gusta limitar la cantidad de código no desarrollado internamente que tenemos que usar en nuestros proyectos, especialmente cuando ese código externo depende de otras bibliotecas desarrolladas externamente.

Básicamente se reduce a: una solución general no siempre es la "correcta".

Estoy seguro de que alguien que realmente trabajó con la biblioteca podría comentar mejor.

Salgo en StackOverflow y no uso el impulso. Agregaré mi razón, porque todavía no se menciona.

Boost tiene muchas ideas geniales, de verdad. Me gusta mirar lo que han hecho y probar nuevas cosas e ideas. Son geniales, porque es un caldo de cultivo para muchas mejoras de C ++.

Pero el impulso es una bestia muy difícil de manejar por muchas razones. Una de las razones es que necesitan (quieren) ser compatibles en prácticamente cualquier compilador con alguna peculiaridad. Como resultado, necesitan emplear muchos trucos, como MPL para lograrlo. Por ejemplo (hace mucho tiempo) quería usar su shared_ptr, hacerlo funcionar significaba que necesitaba las fuentes y las bibliotecas de lo que parecía un 90% de impulso. Terminé escribiendo el mío; 50 líneas de código legibles. (Mis requisitos eran más estrictos, como no débil_ptr o seguridad de subprocesos).

A menudo necesita un pequeño subconjunto de impulso, pero integrar la totalidad del impulso simplemente no vale la pena.

Editar :

Solo queda claro, ya que parece que no se ha presentado claramente (es decir, un voto negativo). Yo uso no utilizar bibliotecas de terceros. Pero en la mayoría de los casos, si todo es igual, integrando una biblioteca de terceros o impulsada, la otra biblioteca de terceros es más rápida y limpia. El resto se realiza en ejercicio de dedos "2h". Echo un vistazo muy duro en la pregunta de compilarlo o comprarlo.

En nuestro caso (no juegos), tenemos una gran razón para no usar boost (ni estándar): tenemos una gran cantidad de código que se remonta a una década. Según las personas de la tercera edad, STD y boost eran incompletos, estaban llenos de errores o eran demasiado lentos para las cosas de alto rendimiento que requerimos. Entonces, se implementaron algunas clases base, utilizando los mismos conceptos (como iteradores) y, a menudo, optimizadas para nuestros algoritmos. Hoy en día, las tres bibliotecas (la nuestra, std y boost) son muy similares.

¿Pero queremos portar todo nuestro código? Realmente no. Asumo que muchas otras compañías enfrentan el mismo dilema. Reescriba muchos códigos probados y en funcionamiento o no use std / boost.

No utilizo personalmente boost ni ningún otro código de propósito general al hacer juegos, porque los juegos no son generalmente de propósito general. El tipo de código que puede necesitar para implementar un juego suele ser específico para el desarrollo del juego, no siempre, pero como el 98% (cifra aleatoria) de las veces. Puede agregar esos últimos bits de código desde boost o alguna otra biblioteca, pero probablemente sea mejor solo escribir esas pequeñas partes que necesita aquí y allá.

En una nota al margen, creo que es bastante divertido escribir su propio código en c ++, por lo que nunca he usado boost ni nada parecido.

el legado en las bibliotecas de la casa no es un factor ... la razón principal por la que nadie debería usar boost u otra biblioteca de uso general es porque no están optimizadas la velocidad y la memoria, aunque debo mencionar que Cryengine usa el STL pero compilan se trata de una versión de código abierto llamada STLPort, así que no tenga miedo de usar el STL, simplemente implemente sus asignadores personalizados y estará bien. no use boost aunque.