Cita:
Iniciado por dmorill 
Gracias, lo entiendo, pero en teoría el list puede almacenar más pues, si el vector no encuentra un bloque de memoria suficientemente grande no pude aumentar de tamaño. Pero las list pueden meterse en "huecos" en la memoria, no en bloques.
Sí, pero cada elemento de un list ocupa más que un elemento de vector... luego el consumo de memoria de un list siempre va a ser superior....
Cita:
Iniciado por dmorill He hecho esta prueba, uso visualStudio 2013 por eso el tamaño del int es de 2147483647.
Ya lo he comentado otras veces... usar los tipos nativos de C++ empieza a considerarse una práctica obsoleta por lo variable del rango de valores. La librería
stdint tiene disponibles tipos de tamaño fijo independiente de la plataforma, lo cual garantiza un rango de valores fijo... algo extremadamente importane en muchísimos algoritmos.
Por cierto, como complemento a
stdint, tienes a tu disposición
inttypes, que te proporciona macros útiles para imprimir variables de rango fijo independientemente de la plataforma utilizada.
Cita:
Iniciado por dmorill Y es muy raro, el maxi size (tengo 16 gigas de ram) es de 357.913.941 y el código falla cuando el vector tiene poco más de 7.900.000.
¿Por qué es raro? Estás creando un vector de vectores. Estás creando 7.900.000 vectores y en cada vector almacenas 50 elementos. Si haces un sizeof de vector en mi caso da 12 bytes. A esto tienes que añadir la información RTTI que acompaña por defecto a cada clase de C++ (lo que permite que funcione dynamic_cast entre otras cosas y que no sale con sizeof, por lo que no se tendrá en cuenta en los cálculos pero que sepas que también está)
Con todo esto el consumo aproximado de memoria es:
Por cada vector: 12 + 50 * 4 = 212
En total: 7.900.000 * 212 = 1.674.800.000 bytes = 1.56 GB... como puedes ver el consumo no es despreciable. A eso tienes que añadirle que cuando
v hace un realloc fuerza un realloc en cascada de todos los vectores almacenados en
v, luego el consumo de memoria implicado en el realloc es considerable. Piensa que detrás de una simple acción puede desatarse una cadena de acontecimientos castastrófica.
Cita:
Iniciado por dmorill Otra cosa que no entiendo bien es porqué este resultado se altera si lo corro en debug, es decir falla a los 5 millones en debug no a los 7 millones como en release.
Esto es porque en debug se añaden marcas que facilitan la depuración del código... y esas marcas tienen la mala costumbre de ocupar recursos.
Cita:
Iniciado por dmorill El problema no es que falte memoria creo, sino que el vector no aumenta más a pesar de que está dentro de sus capacidades.
Cita:
Iniciado por dmorill Haciendo lo que me recomendó eferion hice esta prueba...
Y "sorprendentemente" falla antes. Lo único que has hecho con eso es que el vector principal acapare más memoria... más memoria consumida por el vector principal = menos cantidad de vectores secundarios... ¿sigues pensando que no es un problema de memoria?
La memoria tiende a fragmentarse... esto es, empieza a tener huecos. Cuanto más uso se le da a un equipo más fragmentada suele estar. Si resulta que el sistema operativo no es capaz de encontrar un hueco lo suficientemente grande como para ubicar la cantidad de memoria que se le pide, el proceso simplemente falla. Si tienes 16 GB de memoria bastan 15 bytes ocupando puntos estratégicos para que tu sistema operativo no sea capaz de reservar paquetes superiores a 1GB