Cita:
Iniciado por razpeitia 
Claro que me refiero al STL, hay un montón de código que no utilizara. Ya sea como métodos de clases que solo ocuparan espacio.
Discrepo ligeramente.
Un ejemplo lo tenemos precisamente en los contenedores por el simple hecho de ser templates. Cuando el compilador se encuentra un template no lo compila directamente, sino que espera a encontrarse usos del template y entonces crea las especializaciones pertinentes... pero que el compilador especialize un template no quiere decir que toque todo el template... puede suceder que únicamente compile aquellas funciones que se requieren en el programa... si un template tiene 1.000 funciones pero solo usas 4 el compilador puede decidir eliminar el resto del código.
Por otro lado, no creo que sea preocupante que el código tenga algunos cientos (o incluso miles) de líneas de código que no se usan. El consumo de espacio que esto representa es ridículo y no afecta al rendimiento.
Cita:
Iniciado por razpeitia Incluso reutilizando queue, caes en mi punto original, implementas tu propia versión thread safe. Porque STL no te ofrece esa opción.
Los contenedores no son, por el momento, thread safe por que la STL se centra en el rendimiento. La lógica thread safe penaliza el rendimiento y no es necesaria en la inmensa mayoría de los desarrollos. Encapsular un contenedor para que éste cumpla con tus requisitos en entornos multihilo añade prácticamente el mismo overhead que programarte tu propio contenedor, con la ventaja añadida de que tienes menos código que mantener.
Cita:
Iniciado por razpeitia Incluso si lo reutilizas, ahora tienes bugs tuyos mas los del STL.
Veamos:
- Tu programa se apoya sí o sí en la STL para realizar determinadas tareas. No se si el número de programas que evitan la STL llegará al 0,01% del total.
- Tu programa hace uso de funciones del sistema operativo, que tampoco están exentas de fallos...
- Tu programa acaba haciendo uso de librerías externas... que acabas eligiendo tú... y que también tienen su propia colección de fallos
No creo que decir que la STL tiene bugs sea un argumento de peso dadas las circunstancias.
Además, te puedo garantizar que en el proyecto en el que trabajo... una suite con más de 10 millones de líneas de código que usa la STL, Qt, OpenCascade, exceed, flex, boost... y así hasta un centenar de librerías externas... aún no nos hemos topado con ningún bug en la STL que tire por tierra el código ya realizado.
Cita:
Iniciado por razpeitia Incluso si tienes un buen algoritmo, optimizar partes en ensamblador sigue siendo una practica común en el desarrollo de video juegos.
Este tipo de optimizaciones no están al alcance de cualquiera. Mantener código en ensamblador es una tarea bastante compleja porque requiere tener en cuenta muchísimos detalles a nivel de hardware. No hay más que ver el presupuesto que tienen muchos juegos comerciales.
Además, ese nivel de optimización no suele ser para nada necesaria en juegos caseros... los programadores tienen la mala costumbre de querer que sus juegos vean la luz antes de morir de viejos jejejeje
Cita:
Iniciado por razpeitia Solo son opciones, si fuera una aplicación CRUD con diferentes clases de registros, cargándolos de alguna base de datos. Ahí si valdría la pena usar memoria dinámica. No para implementar titles de un mapa (al menos que sean mapas gigantescos, que no creo que vayan a ser grandes).
En c++, usar memoria dinámica puede ser tan sencillo como utilizar la pila. De hecho, cuando una función recibe un parámetro por referencia o un puntero a tí te es imposible saber si ese elemento está en el stack o en el heap... de hecho, te es indiferente.
Por otro lado, por mucho que uses la pila, si no eres capaz de encontrar el equilibrio adecuado a la hora de pasar elementos a funciones (por valor, referencia, puntero) el rendimiento va a ser muchísimo peor que si directamente usas punteros y memoria dinámica en toda tu aplicación.
Cita:
Iniciado por razpeitia Las variables static NO son peligrosas, la ignorancia de como usarlas si. Y esos efectos colaterales (que creo que es lo que quisiste decir). Es simplemente eso, desconocimiento.
Todavía no he encontrado a ningún gurú de C++ que las defienda... más bien todo lo contrario. Y estos son algunos de los argumentos:
- Se pierde la relación de dependencia
- Las variables globales se pueden solapar con las locales... el compilador no te va a avisar y vas a encontrarte con errores bastante puñeteros
- El orden de construcción es totalmente aleatorio, lo que puede suponer un problema
- El orden de destrucción es aleatorio, de echo puede suceder en entornos multihilo que una variable global se destruya cuando todavía queda algún hilo hijo vivo. No digo que pase siempre... pero es algo que puede pasar
Cita:
Iniciado por razpeitia Mi punto es:
Usa arreglos, son simples, funcionan, hacen bien su tarea, no pierdas tiempo y muévete a la siguiente tarea. El la parte de grid o titles, es solo una pequeña parte de todo el juego.
También podríamos decir:
Usa
contenedores de la STL, son simples, funcionan, hacen bien su tarea,
te ahorras código,
su funcionamiento es óptimo,
evitas pegarte con la gestión de la memoria, ...
Cita:
Iniciado por vangodp Asi es.. Es algo en principio muy simples, pero no se engañe que el tamaño puede abrumar. Basta ver juegos como minecraft que tienen un tamaño 'infinito'. Pero claro solo se carga como unos 20 cubitos en todas las direcciones ya al moverte va generando nuevos y borrando los que queden atraz, hay una opcion que te permite digamos que ver mas lejos que lo que hace es que aumenta la cantidad de cubos que puedes ver. Ademas no se cargan cubos que no puedes ver....
Es algo más complicado que eso. Tienes que separar la información del mapa de la representación gráfica. Tener el mapeo de un millón de cubos de minecraft en memoria no debería suponer ningún reto para un equipo normalito. Como ejemplo, imagina que la clase "Cubo" almacena la siguiente información:
Código C++:
Ver originalstruct Cubo
{
int posX, posY;
int tipo;
};
En este ejemplo se necesitan 12 bytes por cada cubo, 12 millones de bytes en total o 11,5 MB de memoria.
El problema se encuentra en la parte geométrica... y es que forzar a la tarjeta gráfica a calcular la representación de 1 millón de cubos, cuando el 99% de los mismos van a estar ocultos sí o sí puede ser un trabajo titánico para la tarjeta gráfica.
El juego en estos casos suele cargarse la geometría de todos los cubos que estén a X distancia de la cámara, de forma que le ahorras una cantidad ingente de trabajo a la tarjeta gráfica.