PureBoard

Ich benutze immer meine eigene TreeLL, weil die so schön mit Macros
funktioniert und auch keine Daten rumkopiert, wie STARGATEs.

ich hab da auch meine macro besteleien. mit ein paar zusätzlichen möglichkeiten wie rekursiver iteration (also mit unterlisten / childs), oder iteration von hinten nach vorn: auch macros zu verdanken: die möglichkeit, in prozeduren den iterator direkt als z.b. protected zu deklarieren (siehe erster code-teil)

NicTheQuick hat geschrieben:Ich benutze immer meine eigene TreeLL, weil die so schön mit Macros
funktioniert und auch keine Daten rumkopiert, wie STARGATEs.

Jo klar, Marcos sind halt schneller, und mir ist auch klar das das "rumkopieren" eigentlich totaler Zeitfresser ist, aber mir ging es ja nicht um Zeit sonder um Form.

Vllt finde ich ja noch n variante das alles mit Maros zu machen...

Aber erst mal versuche ich den Hinweis von mk-soft zu bearbeiten:

Leider doch ein Problem mit Speicherlecks bei DeleteElement und ClearList. Du gibst den Speicher nur mit FreeMemory frei aber nicht den verwendete Speicher der in der Struktur verwendeten Strings.

So Das Update 1.3.1.0 ist hochgeladen:
(Link auf Seite 1 erneuert)

Nun funzen die Proceduren DeleteElement_(), ClearList_() und FreeList_() zuverlässig, sodass wirklich keine "Reste" von alten Strings mehr übrig bleiben (Noch mal danke an mk-soft, der dies ermöglicht hat).

Auf Grund dieses Updates mussen allerdings die Structuren für die LinkedListen anders Definiert werden, wie ihr es im Beispiel auf der 1. Seite seht.
Structure_(StructureName) und EndStructure_(StructureName) sind Macros die dann die notendigen Dinge mit einbauen.

UPDATE 1.4.0:
- verschiedene IndexFehler behoben
- Bugs bei Elementreihenfolge behoben in verbindung mit FirstElement und LastElement
- Erweiterung für 64Bit Pointer.

Dank eines Forummitglieds wurde ich noch als ein paar (Teilweise) doch sehr schwerwiegende Bugs hingewiesen, in verbingung mit den Listensprungbefehlen (FirstElement, LastElement).

Außerdem habe ich die Include auf für 64Bit Pointer "vorbereitet", wäre nett wenn einer mal unter einem 64Bit System testen könnte ob die Include mit dem Beispiel geht:

Links nicht mehr verfügbar!
Seit PB 4.50 nicht mehr nötig!

ich überleg grad über die technik dahinter.....

eine Struct ist ja eigentlich ein in der Länge festgelegter Datensatz.
einen klassischen Datensatz erstellt man dann, indem man nur fixedstrings verwendet.

die verwendung variabler strings durchbricht dann das Schema,
indem in der struct nur noch der pointer auf den variablen string verbleibt.

daraus folgt, man kann ein ähnliches prinzip anwenden,
indem in der struct selber nur ein pointer auf die embedded-list verbleibt,
und die eigentliche embedded list in einem extra verwalteten pool angelegt wird.

.....hast du das so ähnlich gelöst? nurn bissel tea-talk...

ich habe ehrlich gesagt nicht ganz verstanden was du da geschrieben hast. Deswegen schreibe ich jetzt auch einfach mal wie ich das aufgebaut habe:

Jedes Element hat einen Eigegen Erzeugten speicherbereich, mit der Länge der Structure (+ Pointer für voriges und nächstes Element).
Ob da nun variable String, Longs, Floats,... in der Structure dieser Liste sind, ist dabei nicht schlimm, da der String selber sowieso seinen eigenen Pointer hat, und dieser wird mit geschleppt.
Je nach dem, welcher Befehl ausgeführt wird, wird dann der jeweilige Speicherbereich in den Speicher der Benutzen Variable kopiert und beim wechsel des Elements wieder in seinen eigenen Speicher.
Die ganzen SpeicherLegsProbleme hat netterweise mk-soft gelöst, also String-Speicher nachträglich freigeben wenn der Pointer gelöscht wurde, usw.

Bildlich gesehen ist meine LinkedList eine Schulmappe in der Hefter sind. Je nach dem welcher Hefter gebraucht wird, wird dieser kurz auf denm Tisch gelegt und beschrieben und dann wieder in die Mappe gelegt.

Hinweis, das Primärziel war dabei nicht auf die schnelligkeit zu achten, sonder auch die einfache Handhabung, so wie die PB-LLs sind.

Für tea-talk wäre ein Chat besser

ok.. ich fussels mal auseinander...
mal angenommen, du hast ein strukturiertes Array... erzeugt einen fortlaufenden Speicherbereich von 1000 * 52 Bytes Länge.

das ist die klassische Form.
Natürlich würde man eher ne Liste verwenden, aber als File zum speichern hätte es wieder diese klare Form.

einen variablen String zu verwenden, würde dazu führen, dass man eine variable Datensatzlänge erreicht.
klassisch ist das unpraktisch, weil das Suchen eines Datensatzes in der Datei schwieriger wird.
wenn man feste strings hat, hab man ein festes Offset pro Datensatz.

Wenn ich jetzt in eine Struct eine Liste einfüge, dann hab ich genauso ein heillos unkontrollierbares Datengemisch in variabler Länge, wie ich das bei variablen strings habe.
wünschenswert wäre, wenn diese dann irgendwo in einem festen Pool liegen würden, was gewiß Freds Ursprungsidee bei seinem variablen String-Konzept war.
Aber wenn man die zusammenklauben muss, aus verstreuten Einzelelementen, die sich mit anderen angeforderten Speicherbereichen vermischen können, wird das ganze schwierig händelbar....

....nur mal eben ein wenig tea-talk-like "remember the roots to stay clear"...

STARGÅTE hat geschrieben:UPDATE 1.4.0:
- Erweiterung für 64Bit Pointer.

[...]

Außerdem habe ich die Include auf für 64Bit Pointer "vorbereitet", wäre nett wenn einer mal unter einem 64Bit System testen könnte ob die Include mit dem Beispiel geht:

Öhm, PB ist doch aktuell nur ein 32Bit-Compiler, dass heißt egal ob 32-Bit
oder 64-Bit OS ... das Programm arbeitet mit 32-Bit. Da gibs also nix zu
testen

MFG PMV

Kaeru Gaman hat geschrieben:die verwendung variabler strings durchbricht dann das Schema,

Zurzeit nutze ich Strings, um ebenfalls "Lists" in "Lists" zu haben.

Allerdings quäle ich mich dann immer mit dem Durchsuchen meiner Strings. StringField(), FindString() ...

Longints werden immer mit STR() umgewandelt, anschließend
mit VAL wieder zurück gewandelt, und dann erst benutzt

Ich denke an Datenbank-Verknüpfungen, wo es Eltern- und Kinderobjekte gibt.

Zum Beispiel TAGs, die einem Element zugewiesen werden müssen, die TAGs selbst aber auch eigentlich Datensätze aus der Hauptliste sind.

Zum Beispiel: Element "Paul" ist verwandt mit Element aus der selben Liste: "Erna", "Heinz", "Katrin"

Da jeder Datensatz eine ID hat, bräuchte man nur eine Liste von IDs
Ähnlich hier:
http://www.purebasic.fr/german/viewtopic.php?t=15857

Die Nutzung von Strings hat zwar auch seine Vorteile, so kann ich Namen für meine Objekte eingeben, aber was die Geschwindigkeit angeht, möchte ich doch stark bezweifeln, dass das sinnvoll ist.

Da Strings in PureBasic dynamischer Länge sind, sollte es nicht unmöglich sein, dass LinkedLists() auch in LinkedLists() erlaubt sind.

PureBasic 4.3 vielleicht