PureBoard

Was ich mich schon immer gefragt habe, es aber noch nie wagte.... oder so...

Verwendet ein von Purebasic kompiliertes Binary einen Garbage Collector, oder wird der Speicher anderartig verwaltet?

Mir gehts hier nicht um Leaks (das schaffte ich selbst bei manuellem Verwalten noch nicht....), sondern um die Suche nach einer Plattform für komplexere Soundsynthese (abseits von C, C++, Nim oder Rust - selbst Newlisp ist dafür geeignet, Common Lisp eher weniger, und auch kein Java oder ähnliches). Ich mag von vornherein blocking GC's aussen vor lassen.
Und... Nun ja, Purebasic mag ich halt sehr, deshalb die Frage.

Purebasic räumt auf

Wie hier z.B. aus der Hilfe ersichtlich:

Alle verbliebenen reservierten Speicherblöcke werden automatisch freigegeben, wenn das Programm endet.
Alle verbliebenen reservierten dynamischen Struktur-Einträge werden automatisch freigegeben, wenn das Programm endet.
Alle noch offenen Fenster werden automatisch geschlossen, wenn das Programm endet

Willkommen zurück.

Bei den normalen PB-Funktionen (Window, Gadgets usw.) übernimmt PB die Speicherverwaltung selber bzw. gibt PB die offenen Handles (PB-IDs) automatisch beim Programmende frei. Falls du was anderes meinst, dann sorry.
Wie es während der Laufzeit aussieht, habe ich leider nicht so viele Informationen.

Purebasic hat keinen Garbage Collector. PB-eigene Objekte werden notfalls am Programmende wieder freigegeben, aber globale Resourcen, die du selbst alloziert hast, musst du selbst wieder freigeben, damit es zu keinen Speicherlecks kommt. Oder wenn du zum Beispiel irgendwo AllocateMemory() oder AllocateStructure() nutzt, solltest du auch nach der Nutzung wieder FreeMemory() bzw. FreeStructure() nutzen, sonst gibt es auch hier Speicherlecks.

Danke für die Erläuterungen!

Beim Programmende wird alles, was noch nicht freigegeben wurde, automatisch freigegeben.
So steht es jedenfalls in der PB-Hilfe bei CloseFile(), FreeMemory(), FreeStructure(), FreeGadget(), FreeFont(), CloseFTP() usw.:

• Alle noch offenen Dateien werden automatisch geschlossen, wenn das Programm endet.

• Alle verbliebenen reservierten Speicherblöcke werden automatisch freigegeben, wenn das Programm endet.

• Ein Gadget wird automatisch freigegeben, wenn etwas wie folgt passiert:
  

  • Das Fenster, welches das Gadget enthält, wird geschlossen.
  • Das übergeordnete Gadget (ContainerGadget(), PanelGadget() etc.) wird freigegeben.
  • Das Programm endet.

• Alle bestehenden FTP-Verbindungen werden automatisch geschlossen, wenn das Programm endet.

• usw.

Sind innerhalb einer Procedure Variablen erstellt worden, werden diese automatisch nach dem Ausführen der Procedure freigegeben, außer die Variablen wurden mit folgenden Befehlen erstellt: Static oder Global
Speicherbereiche, die per AllocateMemory() oder AllocateStructure() reserviert wurden, existieren so lange bis sie per FreeMemory() oder FreeStructure() freigegeben oder das Programm beendet wurde.

.....
wenn man natürlich externe Prozesse/Programme/Dämonen/geteilte Bibliotheken aufruft können evtl. Funktionen auch nach dem normalen Programmende existieren.

PureBasic Programme allokieren eine bestimmte grösse an Heap-Speicher, für Variablen, Strings, Handles, Memory usw. Dieser kann bei Bedarf vergrößert werden (AllocateMemory usw.). Wenn dieser Speicher nicht freigegeben wird, macht Windows dies automatisch am Programmende, so das PB da nichts mehr für tun muss. Diese Freigabe geschieht aber nicht unbedingt sofort!
Anders sieht es aus, bei per API angeforderten Speicher. Dieser ist entsprechend freizugeben.

Wie wird das intern eigentlich geregelt, wenn ich auf AllocateMemoy() verzichte? Welche Nachteile entstehen mir dadurch?
Muß ehrlich sagen, bis jetzt habe ich den Befehl noch kein einziges Mal benutzt.

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.