Cita:
Iniciado por razpeitia 
2. Tu eres responsable del manejo de la memoria.
Sobre este tema hay varios frentes diferentes. Yo prefiero no tener que estar bajando constantemente a este nivel... para eso me pongo a programar en ensamblador y controlo hasta las interrupciones del procesador.
Si tengo que hacer una reserva a nivel local dentro de una función por ejemplo, prefiero embutirla en un unique_ptr que dejar el puntero crudo. El overhead es despreciable, no tengo que preocuparme del delete y, si se provocan excepciones no se crean lagunas de memoria.
Por supuesto, cada uno tendrá sus prioridades, yo prefiero centrar mis esfuerzos en que la aplicación funcione correctamente más que en desesperarme por las lagunas de memoria... sobretodo si se trabaja dentro de un grupo grande de trabajo.
Cita:
Iniciado por razpeitia 3. Hoy hay overhead al acceder a un elemento.
Implementación del operador de indización de la clase vector:
Código C++:
Ver originalreference
operator[](size_type __n) _GLIBCXX_NOEXCEPT
{ return *(this->_M_impl._M_start + __n); }
Varios detalles sobre la función:
* Está implementada en la cabecera, luego en "release" será implementada como "inline"
* Hace los cálculos mínimos para cargar el puntero a la posición pedida. No se puede optimizar más.
Conclusión: overhead 0 o insignificante.
Cita:
Iniciado por razpeitia 4. Incluso si el mapa es grande, no ocupas tenerlo todo cargado en ram al mismo tiempo.
No estoy para nada de acuerdo con este punto.
Me explico: Que tengas un mapa en vez de un arreglo no quiere decir que tengas que tener todo cargado en memoria... además, los contenedores de la STL pueden manejar también punteros en vez de elementos por valor; luego las posibilidades de configuración son amplísimas.
Un contenedor, bien elegido, es prácticamente idéntico a tener un arreglo... con la ventaja de que te puedes despreocupar de parte del código porque sabes que va a funcionar.
Pero claro, esto lo dice alguien que es partidario de usar los contendores :D