Frage zu dyn. Array
-
Athar schrieb:
Siderius schrieb:
float *afTestArr;
afTestArr = (int*) malloc((iReadingPoints/2)*sizeof(int))
Wie kommst du erst auf float und dann auf int?
for(i = 1; i <= (iReadingPoints / 2); i++) { afTestArr[i] = i * fHelpValue; }
Indizes fangen in C bei 0 an, du schreibst hier also über die Arraygrenzen hinaus.
Pläze im Array freigegeben werden sonder 4158
Was meinst du mit freigeben? Und wie kommst du auf diese Zahl?
-
wie muss es denn dann aussehen?
-
Es hat einen Grund, dass ich da mit 1 anfange, da eine übergeordnete Funktion standartmäßig mit 1 anfängt.
-
Ich komme ja nicht auf die zahl, sonder C. es sollten iReadingPoint/2 Plätze im Array sein, es sind aber 4158. Woher diese Zahl kommt, weiß nicht nicht. iReadingPoints ist ein Übergabeparameter des Users und somit vorher festgelegt.
-
-
- wie muss es denn dann aussehen?
Meinst du das ernst? Fragen wir anders herum: was in aller Welt verleitet dich in der zweiten Zeile mit int zu hantieren, wenn du ein float-Array willst?
- Es hat einen Grund, dass ich da mit 1 anfange, da eine übergeordnete Funktion standartmäßig mit 1 anfängt.
Du schreibst über die Arraygrenzen hinaus. Wenn du bei 1 anfangen möchtest, musst du das Array eben größer machen!
- Ich komme ja nicht auf die zahl, sonder C. es sollten iReadingPoint/2 Plätze im Array sein, es sind aber 4158. Woher diese Zahl kommt, weiß nicht nicht. iReadingPoints ist ein Übergabeparameter des Users und somit vorher festgelegt.
Ich frage nochmal: woher nimmst du diese Zahl? C wird sie dir sicher nicht telepathisch übermittelt haben.
-
[quote="Athar"]
- wie muss es denn dann aussehen?
Meinst du das ernst? Fragen wir anders herum: was in aller Welt verleitet dich in der zweiten Zeile mit int zu hantieren, wenn du ein float-Array willst?
Stimmt ja, konseqeuente Dummheit. Ich hatte iwie im Kopf dass da der Datentyp von der Anzahl der Werte reinkommt. *grummel*
- Es hat einen Grund, dass ich da mit 1 anfange, da eine übergeordnete Funktion standartmäßig mit 1 anfängt.
Du schreibst über die Arraygrenzen hinaus. Wenn du bei 1 anfangen möchtest, musst du das Array eben größer machen!
ist auch klar. ich hab jetzt das Array um den einen schritt erhöht.
- Ich komme ja nicht auf die zahl, sonder C. es sollten iReadingPoint/2 Plätze im Array sein, es sind aber 4158. Woher diese Zahl kommt, weiß nicht nicht. iReadingPoints ist ein Übergabeparameter des Users und somit vorher festgelegt.
Ich frage nochmal: woher nimmst du diese Zahl? C wird sie dir sicher nicht telepathisch übermittelt haben.
Ganz ehrlich ich habe keine Ahnung woher diese Zahl kommt. Ich kann rein theoretisch 4158 Werte in das Array schreiben. Habe aber im gesamten Programm nicht einmal diese Zahl verwendet.
- wie muss es denn dann aussehen?
-
mngbd schrieb:
Dann kannst du dir den malloc()-Aufruf eigentlich gleich sparen.
.Wie mache ich dass denn dann, wenn ich vorher schon eine feste größe aus einer anderen Funktion habe ?
-
Siderius schrieb:
Ganz ehrlich ich habe keine Ahnung woher diese Zahl kommt.
...
Es ist nicht interessant, woher sie kommt, sondern woher DU sie hast.Siderius schrieb:
Ich kann rein theoretisch 4158 Werte in das Array schreiben.
Genau. Woher weißt du das?
Falls du das ausprobiert hast, indem du die Schleife bis 4158 anstatt iReadingPoints/2 laufen lassen hast: du hast über die Arraygrenzen hinausgeschrieben und damit den Speicher, der hinter dem Array lag, kurz und klein geschossen. Dass du kein segmentation fault bekommen hast, war reine Glückssache.
-
Athar schrieb:
Genau. Woher weißt du das?
Falls du das ausprobiert hast, indem du die Schleife bis 4158 anstatt iReadingPoints/2 laufen lassen hast: du hast über die Arraygrenzen hinausgeschrieben und damit den Speicher, der hinter dem Array lag, kurz und klein geschossen. Dass du kein segmentation fault bekommen hast, war reine Glückssache.Ich habe danach eine Breakpoint gesetzt, debuggt und mir angeschaut, wie viele Werte das Array hat. Beschrieben wurde es korrekt nur sind weitere Plätze verfügbar. Also einfach debuggt und dann in das Array geschaut.
-
Dann weiß der Debugger nicht, wie groß das Array ist und zeigt solange Speicher an, wie er lesen kann oder es handelt sich um eine Eigenheit der Speicherverwaltung...
jedenfalls sind dir nur 2048 Plätze garantiert wenn du nur so viele bestellt hast.
-
Mach doch mal ein printf("%d\n", iReadingPoints/2); vor dem malloc Aufruf. Die Zahl, die du siehst, ist die maximale Anzahl der Elemente, die du beschreiben darfst. Alles darüber ist Russisch Roulette und endet gern mit einer Speicherschutzverletzung (segfault).
Gruß,
B.B.
-
Big Brother schrieb:
Mach doch mal ein printf("%d\n", iReadingPoints/2); vor dem malloc Aufruf. Die Zahl, die du siehst, ist die maximale Anzahl der Elemente, die du beschreiben darfst. Alles darüber ist Russisch Roulette und endet gern mit einer Speicherschutzverletzung (segfault).
Gruß,
B.B.Dann scheint es echt ein Kompilerseitigess Problem zu sein. den printf kann ich leider nicht machen, da ich nicht mit einer Konsole arbeite, sondern eine .dll erstelle die von einer Soft-SPS aufgerufen wird.
Aber danke schon mal für die Hilfe.
-
Siderius schrieb:
- wie muss es denn dann aussehen?
Einfach den Gips weglassen:
afTestArr = malloc(iReadingPoints / 2 * sizeof(float))
Siderius schrieb:
Ich habe danach eine Breakpoint gesetzt, debuggt und mir angeschaut, wie viele Werte das Array hat.
Es ist eigentlich gar kein Array, man nennt das nur meistens etwas ungenau so. Es ist ein Speicherbereich, den man wie ein Array verwenden kann. Begrenzt wird er prinzipiell nur durch deine Vorsicht und die Hardware, alles andere ist schon sehr nett von der C-Bibliothek.
Siderius schrieb:
Wie mache ich dass denn dann, wenn ich vorher schon eine feste größe aus einer anderen Funktion habe ?
Wenn die Grösse zur Compilezeit bekannt ist, und halbwegs klein ist, kannst du das Array auf dem Stack oder im statischen Bereich anlegen.
Siderius schrieb:
den printf kann ich leider nicht machen, da ich nicht mit einer Konsole arbeite, sondern eine .dll erstelle die von einer Soft-SPS aufgerufen wird.
Debuggen ist eine kreative Tätigkeit. Vielleicht ein Logfile machen oder in einer bequemeren Umgebung testen?
Edit: da oben steht jetzt sizeof(float), das ist wahrscheinlich eine gute Idee
Es ist nicht tot, was ewig liegt
Besser: "liegen kann".