Mensajes

Si por defecto solo vas a gestionar un numero conocido y fijo de elementos, 20 por ejemplo, no necesitas nada más que el puntero al principio del vector de elementos... pero si el número es, a priori, aleatorio... necesitas conocer el final.

Es como seguir un camino... si no sabes cual es el final no puedes saber si has llegado por mucho que andes

como ha quedado tu código ahora??

y otra duda tambien de un vector de punteros

por ejemplo si tengo

Código (c) [Seleccionar] Expandir

char *meses[3] ={"Enero","Febrero","Marzo"};
for(i=0;i < 3;i++)
    printf("%s",*meses+i);


aqui me imprime Enero Nero Ero

pero si a la linea del printf le agrego unos parentesis

Código (c) [Seleccionar] Expandir

printf("%s",*(meses+i));

me imprime correctamente Enero Febrero Marzo

no entiendo por que
     

Si tu dibujas el mapa de memoria tendrás que lo que el vector se encuentra estructurado así ( cada letra una posición de memoria ):

'E' 'n' 'e' 'r' 'o' '\0' 'F' 'e' 'b' 'r' 'e' 'r' 'o' '\0' 'M' 'a' 'r' 'z' 'o' '\0'

y dado que "meses" es una matriz de cadena de caracteres, se cumple que:

*meses es igual a *meses + 0 y apunta al primer carácter ( 'E' ).
*meses + 1 es un desplazamiento de una posición respecto a *meses, es decir,  apunta al segundo carácter ( 'n' )
*meses + 2 es un desplazamiento de dos posiciones respecto a *meses, es decir,  apunta al tercer carácter ( 'e' )
...

Es decir, primero resuelves el puntero *meses y luego incrementas la posición apuntada.

Con esto, si intentas imprimir las cadenas resultantes te sale:

Enero, nero, ero, ro, o, (nada), Febrero, ebrero, ...

Sin embargo, *( meses + i ) es equivalente a moverte primero una fila y apuntar al caracter que esté en esa posición, de tal forma que:

*(meses + 0) o *meses apunta a 'E'
*(meses + 1) apunta a 'F'
*(meses + 2) apunta a 'M'

Al final el cambio viene promovido porque los paréntesis cambian el orden en el que se ejecutan las operaciones... no es lo mismo resolver un puntero doble y luego incrementar su posición que incrementar un puntero doble y resolver su posición.

Estaba un poco ofuscado cuando te escribí y creo que no fui lo suficientemente claro, perdón.

Lo que quería decir es que al final tienes que trabajar con posiciones de memoria puras y duras... si quieres que una función procese un vector de cualquier longitud necesita una posición de memoria por la que comenzar y una de dos, o bien una posición de memoria en la que terminar, o bien el número de elementos.

Pero lo que está claro es que, con solo una posición de memoria no hay forma de saber en qué punto has de terminar de procesar elementos, siempre necesitarás algo que te diga cuándo terminar.

Perdona pero no, cualquier compilador actual convierte tu matriz en un vector unidimensional. Por esa razón tienes que indicar el número de columnas cuandos pasas una matriz como parámetro a una función.

Otra cosa son las matrices "dinámicas" que creas con malloc/new. Se suelen hacer con un array de punteros (y ahí si hay perdida de rendimiento porque tienes que redireccionar dos veces).

eso mismo.

En concreto Oblivi0n, una matriz de .net tal que:

Código (csharp) [Seleccionar] Expandir

int[,] arr4 = new int [2,3] { {1,2,3}, {4,5,6} };

Reserva la memoria de forma lineal, no podía ser de otra forma, y tal que los elementos van en el siguiente orden: 1, 2, 3, 4, 5, 6 ... por tanto, para acceder a un elemento de la segunda fila necesitas hacer un salto... las matrices tienen tantos niveles de indirección como dimensiones posean.

Vector: 1 dimensión -> 1 nivel de indirección
Matriz típica: 2 dimensiones -> 2 niveles de indirección
...

Código (c) [Seleccionar] Expandir

_temp[i] = dat.topScore[i];

ahí estás sacando datos de dat y guardándolos en _temp... dat no lo estableces en ninguna parte del código que has puesto.

Así a bote pronto no veo dónde has guardado los datos en dat...

No es que te esté guardando mal los datos... es que no los estás guardando.

Por partes:

Código (c) [Seleccionar] Expandir

float z[100];

En esa línea estás creando un vector de floats... has de saber que cada float, por si mismo, no sabe nada de su entorno:

* No sabe que pertenece a un vector
* No sabe qué posición ocupa.
* No sabe cual es el elemento anterior ( si tiene ).
* No sabe cual es el elemento siguiente ( si tiene ).

La única forma de saber el orden del vector es mediante el vector z.

Este coñazo te lo explico porque ahora, en esta línea:

Código (c) [Seleccionar] Expandir

procesar(&z[50]);

Estás pasando la posición de memoria donde se encuentra el elemento número 50 del vector... pero claro... ese elemento no tiene ni idea de lo que tiene a su alrededor... es un simple puntero a un float.

Si quieres que tu función recorra un número de elmentos consecutivos tienes que indicar la posición inicial dentro del vector y la final... la primera te servirá para saber dónde empezar el recorrido y la segunda para saber cuándo has terminado.

Dicho con código... tu llamada tendría que tener, por ejemplo, esta forma:

Código (c) [Seleccionar] Expandir

procesar(&z[50], &z[99]);

Le pasas el primer elemento de la secuencia, es decir, el 51 ( recuerda que los índices empiezan a contar desde el 0 ), y el último el 100.

Y la función tendría que tener una cabecera tal que...

Código (c) [Seleccionar] Expandir

void procesar( float* f_ini, float* f_fin )

Y ahí ya tienes todo lo necesario para trabajar... solo tienes que ir incrementando el puntero f_ini hasta que coincida con f_fin y listo.

Recuerda que f_fin también forma parte del array... por lo que también has de procesarlo.

Y luego tienes la opción b... que es pasar el puntero a la primera posición a procesar dentro del vector y a la vez el número de elementos a procesar:

Código (c) [Seleccionar] Expandir


// ...
procesar( &z[50], 50 );
// ...

void procesar( float* f, int longitud )
{
  // ...
}

En este caso tendrás que llevar tú la cuenta del número de incrementos en el puntero f para no pasarte.

Es lo malo de las librerías gráficas... si haces algo mal el resultado puede no darte ninguna pista que te ayude a encontrar el error... y depurarlo también tiene su miga.

Recuerdo una de mis primeras prácticas de opengl... me estuve dando de cabezazos porque no me pintaba la escena y era por un parámetro erróneo al ubicar la cámara ( en vez de un 1 era un 0 o al revés ) ...

Venga, el código se entendió, gracias a todos por los comentarios.

jajajajaja deja deja, que yo así también recuerdo cosas olvidadas