PureBoard

Naja, man kann Strukturen (ich denke, darauf läuft es hinaus) ja auch als Variable oder als strukturiertes Array oder Liste benutzen. Da braucht man dann kein AllocateMamory() für.

Siehe auch Beispielcodes in der Hilfe unter "Strukturen".

Was Strukturen angeht, arbeite ich ausschließlich mit LinkedLists.

ts-soft hat geschrieben:Wenn Du auf AllocateMemory verzichtest, gibt es über kurz oder lang einen IMA. Kompilierst Du etwa ohne Debugger?
Der purefier in den CompilerOptionen sollte Dir helfen, Speicherfehler zu erkennen, aber der springt dann sofort an.

Nee, kompiliere immer mit Debugger; Purifer müßte auch aktiv sein (obwohl ich mit dem noch nie wirklich gearbeitet habe). Noch nie einen Fehler bekommen.
Worauf ich penibel achte, daß ich temporäre Arrays, Listen und Sprites freigebe, sobald ich diese nicht mehr brauche.
Hier und da benutze ich auch den CopySprite-Befehl - habe gemerkt, daß man damit eigentlich immer ein FreeSprite() benötigt, ansonsten kann bei wiederholtem Benutzen schnell der Speicher zulaufen.
Was ist ein IMA?

Ein IMA ist ein Invalid Memory Access, also ein ungültiger Speicherzugriff.

Gerade bei meinem Projekt das ich vorhabe ist AllocateMemory und Freunde gar nicht so schlecht. Die Möglichkeit mit peek und poke große Bereich ressourcenschonend abzuackern ist denke ich für Soundsynthese essentiell. Ich denke gerade für diesen Zweck ist manuelle Speicherverwaltung (das ist es mehr oder weniger ja!) essentiell. Mir ging es um das rundherum (kann es sein das ein GC das abackern vom Speicher stottern lässt?....) - und da scheint PB genau so zu machen wie es für mich nun für den Zweck Sinn macht.
Jetzt wird aber erstmal über Carrier und Modulatoren gelernt

Statt mit Peek und Poke solltest du lieber mit Pointern arbeiten. Die sind dafür einiges schneller und wenn man sie mal kapiert, meistens sogar einfacher zu handhaben

@diceman

ein IMA tritt nur auf den man mit einen Pointer auf ein nicht definieren Speicher zugreift.
Du arbeitetest ja mit Pointer auf Listen oder Arrays. Wenn du also immer darauf achtest, das der Pointer auf ein gültigen Eintrag verweist, ist dieses kein Problem.

Arbeite auf sehr viel mit Pointern und vereinfacht viele Funktionen zur Übergabe von Daten...

Ja, dann weiß ich was du meinst, danke für die Erläuterung.
Einen solchen IMA hatte ich in der Tat ein paar Mal, aber ich konnte das jedesmal auf einen fehlerhaft adressierten *pointer zurückführen.
Pointer = <3 <3 <3

Na, ich denke solch ein Thread ist nicht schlecht - man liest mehr heraus als man vorerst ahnt!

Und jetzt: ab an den See und weg vom Computa!

Anstattkann man auchnehmen.
Der Vorteil bei der AllocateMemory()-Variante ist, dass man darauf reagieren kann, wenn der angeforderte Speicher nicht reserviert werden konnte (AllocateMemory() liefert dann eine Null-Adresse zurück).
Bei der ByteArray()-Variante würde das Programm vermutlich einfach abstürzen, wenn die Speicheranforderung zu hoch ist.

Wenn also mit sehr großen Daten hantiert wird, ist es besser mit AllocateMemory() oder AllocateStructure() zu arbeiten, anstatt mit normalen Variablen.

Edit:
"Dim" durch "Global Dim" ersetzt

Ein Memory (nicht der Zeiger) ist aber immer gültig, eine Variable (ByteArray) hat aber einen festgelegten Gültigkeitsraum!