Ich möchte dich zu deinem Werbeetat beglückwünschen!
https://i.imgur.com/DgPST1s.jpg

Ich wollte auch noch kurz einen Kommentar abgeben, allerdings zum Spiel und nicht zur Technik :
Mir gefällt deine Idee richtig gut, sie ist wirklich sehr kreativ und ich bin schon sehr gespannt auf eine erste spielbare Version (die es hoffentlich bald geben wird ). Ist seit Langem mal wieder ein interessantes und spannendes Projekt hier im Forum.

MFG Lador

In Java (wie auch Python) sind weak references nicht nötig, da der GC nicht nur Referenzen zählt, sondern auch Zyklische Referenzen erkennt. In BMax wird ein Objekt erst dann freigegeben, wenn es keine Referenzen mehr darauf gibt. Das heißt, wenn man die letzte outside reference auf eine zyklische Referenz verliert hat man ein Memory Leak das man nicht mehr recovern kann.

In Java und Python wird ein Objekt freigegeben wenn es keine Verbindung von dem Objekt zum Global Space/Local Space/Stack mehr gibt. Das heißt, wenn man die letzte outside reference auf eine zyklische Referenz verliert, dann wird selbige Referenz vom GC gefressen.

Was heißt "nicht gut" -- Mein Java ist ein bisschen eingerostet, aber da erinnere ich mich auch nicht an "unowned" und "weak references," da gab es auch nur die einfache Unterscheidung: ist Referenz da oder nicht. Das ist dann ja keine Idiotie vom GC, sondern einfach nur eine Beschränkung der Sprache

Es gibt eine Wrapper-Klasse, WeakReference<T>: https://docs.oracle.com/javase...rence.html

Analog dazu den Bmax-Vorschlag: https://github.com/bmx-ng/brl.mod/issues/108

Worklog-Kommentare zu kommentieren ist leider maximal umständlich. Fände eine Diskussion in einem separaten Thread aber interessant

@Thunder:
Du hast natürlich recht. Es ist schon eine Weile her dass ich in BMax was gemacht hab, hab gedacht es gab ein manuelles Delete. Es ist hald schon blöd, wenn man einen GC hat, der einem das Memory Management abnehmen soll, das aber nicht gut tut...

@DAK: bin mir nicht sicher, wie du dir das vorstellst. Manuelles Memory Management kannst du natürlich machen, aber wie soll das mit BlitzMax-Typen funktionieren? Mit malloc den memory für den Typen bereitstellen und dann hineinkopieren?

Wie soll die Delete-Methode das eigene Objekt löschen? Vielleicht gibt es ja eine Funktion vom GC die ich nicht kenne

Jedenfalls müsste man aufpassen mit dem Namen "Delete". Die "Delete"-Methode wird nämlich vom BlitzMax GC aufgerufen, wenn er das Objekt freigibt. Das heißt mit manuellem Memory-Management kommt es ganz schnell zu double-frees. Es ist übrigens auch nicht garantiert, dass die "Delete"-Methode vom GC jemals aufgerufen wird. Habe das hier dokumentiert: https://www.blitzforum.de/foru...hp?t=39579
Ob das ganze auch für Bmax-NG zutrifft, kann ich nicht sagen.

Brucey, der bmax-ng pflegt, reagiert auf Probleme auf GitHub sehr schnell. Da scheinen noch Leute dran zu arbeiten. Leider haben die keine laufende Test-Suite, sodass viele Änderungen ungeahnte Konsequenzen haben könnten -- wie zum Beispiel mein Problem von neulich: " Abstract base type in different file with Field does not keep Field's value in concrete subclass from other file #417 " (https://github.com/bmx-ng/bcc/issues/417)

Hat sich herausgestellt, dass bmax-ng auch nicht mehr einfach Referenzen zählt. Dann wäre nämlich sehr einfach gewesen, "weak" zu implementieren, indem man bei solchen Referenzen eben den Zähler nicht erhöht. Das wäre eher analog zu Swift/Objective-C, wo retain/release aufgerufen wurden, damit der Garbage Collector weiß, wann er was löschen darf.

Klar, manuelles memory management würde das Problem umgehen. Dafür andere aufmachen. Wie immer

Mist, man kann Worklog-Kommentare nicht editieren... Also falls sich ein Mod bemüßigt fühlt die beiden Posts zu mergen, bitte gerne

Um das Problem in BMax zu umgehen könnte man den ganzen GC auslassen. Dafür gibt man jedem Objekt eine Delete-Methode, die von allen referenzierten Objekten die Delete-Methode aufruft und dann sich selbst löscht. Braucht etwas mehr Hirn und ein explizites Aufrufen der Delete-Methode, aber dafür klappt es zuverlässig und man braucht sich nicht auf den mäßigen GC von BMax verlassen.

Und wenn der BMax-GC zyklische Referenzen erkennen könnte (wie z.B. der Python-GC) dann hätte man das ganze Problem auch nicht. Dann bräuchte man nicht mal mehr sich darum kümmern müssen, welche Referenzen weak oder strong sind.

Der Beitrag zu weak references gefällt mir.
Führt mir schön vor Augen, dass die Uni-Zeit schon ein paar Jährchen zurück liegt... Aber man sich doch mit ein paar theoretischen Eigenschaften von Programmen beschäftigen muss, um sie "gut" zu machen.
Ehrlich gesagt könnte man fast den "Glauben" an Software-Entwicklung verlieren. Wenn ich überlege, wie viele "professionelle" und / oder kommerzielle Programme ich schon gesehen habe, in denen sich die Entwickler nicht um solche Details gekümmert haben...