malloc in unter-funktion, speicher bleibt nicht erhalten?

hallo. ich wollte sowas machen:

#include <stdio.h>
#include <stdlib.h>

void vTest(int* n, int iDim)
{
	n= (int *) malloc(iDim*sizeof(int));//Speicher reservieren
	for(int i=0;i<iDim;i++) *(n+i)=(i+1)*(i+1);//Qudratzahlen reinschreiben
	for(int i=0;i<iDim;i++) printf("%i , ",n[i]);//als test ausgeben: GEHT!
	printf("\n");
}

int main()
{
	int* iArray;
	vTest(iArray,10);//vTest soll iArray initialisieren
	for(int i=0;i<10;i++) printf("%i , ",iArray[i]);// GEHT NICHT!
	printf("\n");
	return 0;
}

ausgabe:

1 , 4 , 9 , 16 , 25 , 36 , 49 , 64 , 81 , 100 ,
1162588 , -1208651776 , -1208465888 , -1209743914 , -1209743898 , -1209743882 , -1209743866 , -1209743850 , -1209743834 , -1209743818 ,

warum kann ich in main() nicht mehr auf die daten zugreifen, die ich im vTest() in das array geschrieben hab? wird der speicher etwa automatisch freigegeben?

gcc (GCC) 4.1.0 (SUSE Linux)

cu

rüdiger

kurz: das nennt man Call-by-value

länger: Du übergibst einen Pointer per Kopie, wenn du den Pointer in der Funktion änderst, änderst du nicht den Pointer in main. Du brauchst also ein Pointer auf einen Pointer

void a(int **ptr, size_t Dim) {
  *ptr = malloc(Dim * sizeof(int));
  ...
}

btw1. es ist nicht gut den Rückgabewert von malloc zu casten! Das ist ein ober pfui!

btw2. Speicher wird in C eigentlich _nie_ automatisch freigegeben. Daher ist es ein Megapfui wenn man kein free aufruft!

btw3. nimmt man für Längenangaben size_t (oder zumindest einen unsigned Typ)

ich teste das, thx.

ich hatte mir die adressen der pointer jeweils ausgeben lassen. die waren immer die selben.

btw1) malloc returnt (void*), c++ castet das nicht automatisch, c schon... steht also soazusagen aus kompatibilitätsgründen dort.

btw2) weiß schon, wollte sicherstellen, dass ich wirklich nichts freigebe. sodass der speicher erhalten bleibt.

was mich zu der frage bringt: wo bleiben meine quadratzahlen dann eigentlich?
"Lost in Heap" teil 2?

ja ich nehm dann unsigned...versprochen...

lw

rüdiger

lawilog_not_logged_in schrieb:

btw1) malloc returnt (void*), c++ castet das nicht automatisch, c schon... steht also soazusagen aus kompatibilitätsgründen dort.

Du programmierst aber C und kein C++. In C++ nimmt man new. Also keine falsche kompatibilität, vor allem wenn sie potentielle Fehler provoziert.

CStoll

lawilog_not_logged_in schrieb:

was mich zu der frage bringt: wo bleiben meine quadratzahlen dann eigentlich?
"Lost in Heap" teil 2?

Ja, sozusagen (fachmännisch ausgedrückt nennt sich das "Speicherleck" und bedeutet, daß die Daten noch irgendwo im Heap liegen, du aber mangels Adresse nicht mehr drankommst.

PS: Nur ein optisches Detail - dieses "*(ptr+i)" kann teilweise verwirrend aussehen, du solltest stattdessen die Index-Schreibweise "ptr[i]" verwenden (ist technisch identisch, aber im Quelltext klarer zu erkennen).

also, wie folgt:
ich gebe mit malloc(pVertices,8000) für 100 Vertices speicher frei ... bei meheren rechneren gibts da dann mehrere fehler (immer die selben aber für jeden rechner unterschiedlich) ...

der debuger sagt dann es wäre der wert "4.344e-044#DEN" typ:float ...

könnte das ein hinweiss auf katastrophales speicher händling sein (das Program nimmt sich nur den speicher den es bis dahin braucht, ok er wird noch nicht wieder freigegeben aber das program ist immoment eh nur bis zum drücken der escape taste an

c.rackwitz

code oder kristallkugeln. eines davon brauchen wir mindestens. deine wahl.

^^ update ...

also meine frage ist wohl eher was fürs spiele forum, da es noch mit "vertexbuffer->lock" zu tun hat *GRML* (scheintmir so als würde da der grafik speicher sich änder, da sich auch der pointer ändert )