Ver Mensaje Individual
  #7 (permalink)  
Antiguo 14/04/2013, 11:05
vosk
 
Fecha de Ingreso: agosto-2012
Mensajes: 601
Antigüedad: 11 años, 8 meses
Puntos: 83
Respuesta: problema crear objeto dentro de un vector

"...esto con vector hay alguna manera?..."

En teoria no. Los pools de memoria se basan en reservar y administrar un bloque de memoria (de forma parecida a como haria un sistema de ficheros):

Código:
void *buffer;//4 bytes en el stack o en el heap o yo que se donde (un puntero)

vector <int> lista;//inicialmente 12 bytes en el stack
lista.push_back(1);//sizeof(int)*10000000
Digo 1000 com podria decir UINT_MAX, no se exactamente para cuantos elementos se hace la reserva, pero es seguro que hace una reserva para mas de 1 elemento (mas de 1 y mas de 10000). Esa reserva no se inicializa a nada, simplemente se reserva memoria que sigue manteniendo los datos usados por el proceso previo (puede ser casualmente un entero o un caracter o un noseque).

Como la administracion de ese pool de memoria la hace el objeto vector en vez del s.o. no existe la opcion (o la casualidad) de que se vaya sobreescribiendo con datos de otros procesos, sino que solo se sobreescribe cuando se le obliga a usar un espacio de su memoria marcado como libre ok?

Puedes comprobarlo tu mismo:

Código:
vector <int> lista;

printf("%d", lista[0]);//b.o.f., direccion de memoria no accesible

lista.push_back(3);
printf("%d", lista[0]);//valor 3
printf("%d", lista[5000]);//valor basura, direccion de memoria accesible pero no inicializada

lista.clear();
printf("%d", lista[5000]);//valor basura, direccion de memoria accesible pero no inicializada

printf("%d", lista.size());//contador interno de elementos disponibles 0

lista[0] = 5;//direccion de memoria disponible, valor previo 3, valor nuevo 5
printf("%d", lista[0]);//valor 5, incluso despues del clear sigue siendo un ruta valida dentro del pool reservado en el primer push_back
Otra cosa: el objeto vector reajusta su pool para albergar los datos necesarios pero no por unidades de elementos sino por bloques, es decir cuando declaras un vector se crea el objeto y su contador interno de elementos accesibles se inicializa a 0, es decir que para cada push_back comprobará si el pool permite el acceso a un nuevo elemento del tamaño declarado, si cabe un nuevo elemento pues se le asigna la posicion de memoria del pool y listos, si no cabe pues se reserva un nuevo bloque de memoria y se asigna la posicion correspondiente.

Y a lo que vamos: en teoria tienes que trabajar con las funciones adaptadas al caso, es decir que si vector::size() te dice que tiene 0 elementos es que no tienes que acceder a ninguno (aun cuando vector[0] exista y tenga incluso un valor real). De esto se desprende que si quieres eliminar un elemento del vector tienes que sobreescribirlo antes de liberarlo (le asignas p.ej. 0); esa posicion seguirá siendo accesible pero tendrá un valor controlado.

Esto es importante a tener en cuento cuando trabajas con vectores de punteros: si reservas memoria para un objeto (pongo el ejemplo con objetos en vez de enteros para exagerar el resultado y que se vea el impacto) y luego guardas en un vector un puntero a ese objeto, el vector en ningun caso controla la validez del objeto, aun cuando finalices y liberes la memoria usada por ese objeto el vector tendra una ruta valida de acceso al dato pero ese dato será a su vez una ruta a una posicion no valida.

Resumen: sobreeescribir, eliminar y bienvenido al apasionante mundo de los memory pools :)

Saludos
vosk