Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht Das deutsche QBasic- und FreeBASIC-Forum
Für euch erreichbar unter qb-forum.de, fb-forum.de und freebasic-forum.de!
 
FAQFAQ   SuchenSuchen   MitgliederlisteMitgliederliste   BenutzergruppenBenutzergruppen  RegistrierenRegistrieren
ProfilProfil   Einloggen, um private Nachrichten zu lesenEinloggen, um private Nachrichten zu lesen   LoginLogin
Zur Begleitseite des Forums / Chat / Impressum
Aktueller Forenpartner:

Verkettete Liste abspeichern und laden?

 
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC.
Vorheriges Thema anzeigen :: Nächstes Thema anzeigen  
Autor Nachricht
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 12.12.2008, 12:24    Titel: Verkettete Liste abspeichern und laden? Antworten mit Zitat

Gibt es einen "einfachen" weg wie man verkettete listen abspeichern und wieder in den speicher laden kann?

Ich denke, das wird keine einfache disziplin sein element für element je nach größe und typ abzuspeichern und dann auch noch dafür zu sorgen das man die liste in der selben reihenfolge wieder in den speicher bekommen kann... Aber vielleicht kennt ja jemand eine universallösung!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Sebastian
Administrator


Anmeldungsdatum: 10.09.2004
Beiträge: 5969
Wohnort: Deutschland

BeitragVerfasst am: 12.12.2008, 12:56    Titel: Antworten mit Zitat

Hallo,

ich würde vorschlagen, dass du einfach die Listenelemente beginnend mit dem ersten in eine Datei schreibst und zum Auslesen nachher Element für Element wieder am Ende der neuen Liste einfügst. Dann sind die Elemente auch wieder in der gleichen Reihenfolge. Beim Speichern kannst du den Pointer auf das nächste Element weglassen, weil beim Wiederneuanlegen der Listenelemente ohnehin neue Speicheradressen zustandekommen.

Viele Grüße!
Sebastian
_________________

Die gefährlichsten Familienclans | Opas Leistung muss sich wieder lohnen - für 6 bis 10 Generationen!
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden E-Mail senden Website dieses Benutzers besuchen
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 12.12.2008, 14:01    Titel: Antworten mit Zitat

Ist aber sehr mühsam traurig
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Mao



Anmeldungsdatum: 25.09.2005
Beiträge: 4409
Wohnort: /dev/hda1

BeitragVerfasst am: 12.12.2008, 14:17    Titel: Antworten mit Zitat

Warum ist das sehr mühsam? Sollte sich doch mit rel. wenig Code bewerkstelligen lassen.
_________________
Eine handvoll Glück reicht nie für zwei.
--
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 12.12.2008, 17:05    Titel: Antworten mit Zitat

Bei "einfachen" udts kann ich mir das sehr gut vorstellen..

ABER ... wenn man sich sowas anschaut wie in meinem Projekt namens "Rechenknecht" :

Code:

[...]

type _in
    in as any ptr    'eigentlich _rk
    nx_in as _in ptr
end type

type _display
    scr as any ptr
    w as integer
    h as integer
    lpx as integer
    lpy as integer
end type

type _rk
    i as _in ptr
    li as _in ptr
    icount as integer
    o(1 to 2) as double
    rtype as integer
    nx_rk as _rk ptr
    x as integer
    y as integer
    display as _display
    flipped as ubyte            '0 = Eingänge links, Ausgänge rechts. 1 = umgekehrt
    declare sub show()          'Rechenknecht zeichnen
    declare sub calc()          'Rechnen!
end type

[...]


Wo Elemente Arrays sein können, oder andere UDTs oder NOCH eine zusätzliche verkettete Liste...

Ich wüsste nichtmal wie ich eine solche liste in eine datei reinquetschen könnte ohne das ich zusätzlich noch die darin angefangenen verketteten listen ablaufe...

Eine funktion die sowas universell kann wäre richtig klasse aber wahrscheinlich wahnsinnig aufwändig wenn sie sich an jede vorstellbare udt anpassen können sollte.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 13.12.2008, 20:38    Titel: Antworten mit Zitat

sage mir, wie willst du alle elemente eines types abspeichern ohne alle elemente des types abzuspeichern?


und da FB keine reflections oder sowas kann bleibt dir nichts anderes übrig, als die felder auch alle direkt einzeln zu behandeln. Einzige alternative wäre, wenn dein type wirklich alle daten direkt enthält (also keine strings oder ähnliche datentypen, welche dynamische größen haben), dann könntest du in eine binär geöffnete datei einfach von dem adresspointer des types entsprechend seiner größe viele bytes in die datei schreiben und genauso wieder auslesen. dennoch wirst du das für jedes listenelement einzeln machen müssen, denn listenelemente zB sind über pointer verknüpft und die anhängende liste ist eben gerade von variabler größe, eine allgemeine funktion zur speicherung von sowas würde gerade reflections benötigen.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Jojo
alter Rang


Anmeldungsdatum: 12.02.2005
Beiträge: 9736
Wohnort: Neben der Festplatte

BeitragVerfasst am: 13.12.2008, 21:17    Titel: Antworten mit Zitat

man kann im binärmodus einen ganzen TYPE PUTten. von daher ist es egal, wie groß der TYPE ist. Reicht also, eine ganze liste durchzugehen.
_________________
» Die Mathematik wurde geschaffen, um Probleme zu lösen, die es nicht gäbe, wenn die Mathematik nicht erschaffen worden wäre.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden Website dieses Benutzers besuchen
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 14.12.2008, 15:27    Titel: Antworten mit Zitat

aber eben nicht wenn der type pointer oder strings zB enthält, dann puttest du nur die adresse, nicht aber den damit verknüpften wert, oder? ;P
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 15.12.2008, 11:14    Titel: Antworten mit Zitat

Ja, eben, mit dem putten hab ich genau diese erfahrungen gemacht. Spätestens bei den pointern die auf das nächste kettenelement verweisen scheitert das komplette putten.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
MisterD



Anmeldungsdatum: 10.09.2004
Beiträge: 3071
Wohnort: bei Darmstadt

BeitragVerfasst am: 15.12.2008, 20:26    Titel: Antworten mit Zitat

richtig, du brauchst da ne datenrekursion und musst halt wirklich nur putten, was daten sind und nicht pointer, und dann halt einfach alle elemente hintereinander.
_________________
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Edsger W. Dijkstra
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 22.12.2008, 11:22    Titel: Antworten mit Zitat

Wie kann ich eigentlich die Elemente einer (prinzipiell unbekannten) udt ablaufen? Vor allem wie kann ich auch noch feststellen um welchen datentyp es sich bei dem entsprechenden element handelt?

Ich würde gerne eine solche Abspeicher-funktion so universell wie möglich halten.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
ThePuppetMaster



Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]

BeitragVerfasst am: 22.12.2008, 13:23    Titel: Antworten mit Zitat

garnicht.

dir muss erstmal bekannt sein, wo sich der pointer auf den nächsten speicherbereich befindet. und dann kannst du versuchen alles andere zu speichern.

als eventuellen versuch könntest du einfach das UDT auseinandernehmen, udn versuchen jeweils immer 4Bytes als Ptr adresse zu nutzen. Anschliessend versuchst du per PTr prüfung, ob dieser Wert gültig sein könnte, oder etwas anderes ist, als das was es sein sollte. Ein Ptr eben.

Wenn du dann einen gefunden hast, der ein Pointer sein könnte, dann musst du prüfen, ob dieser auch auf einen gültigen speicherbereich zeigt. trit das auch noch zu, dann versuchst du diesen speicher auszulesen, und versuchst herauszufinden, ob dort irgend wo ein pointer vorhanden ist, der auf die adresse zeigt, von der du kommst. (wäre besser und sicherer beim prüfen, als eine einfach verkettete liste)

ist das der fall, dann hast du schonmal alle nötigen punkte, um vor und zurück zu laufen, in einer verketteten liste. alles andere is jetzt nur noch hypotetisch. Denn du must herausfinden, wie bereit das UDT ist, um anschliessend die position der pointer zu extrahieren, und alles andere in die datei zu packen.

aber, primär ist es nicht möglich die typen in einem udt zu enumerieren. genauso wie es nicht möglich ist, die grösse eines speichers (unter linux, win, dos, xbox) ohne kentniss des UDTs zu ermitteln.

Wenn ein Betriebssystem vorliegen würde, das ahnand des Pointers die feldgrösse zurückgeben könnte, wär es einfacher, aber win udn linux, sowie dos und xbox untersützten solche funktionen nicht.

tut mir leid, das ist wohl eine aussichtslose sache. eventuell könnte man mit ASM noch vorran kommen, oder aber mit einem linkerskript, das die spezielle parameter vom compilingvorgang ermittelt. aber so siehts mager aus.


MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ]
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
nemored



Anmeldungsdatum: 22.02.2007
Beiträge: 4700
Wohnort: ~/

BeitragVerfasst am: 22.12.2008, 13:41    Titel: Antworten mit Zitat

Was ich mir sonst noch vorstellen könnte, wäre ein "Universal-Datentyp", der speichert, welche Art von Daten er enthält und wo sich der Inhalt befindet (PTR).
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1.
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
OneCypher



Anmeldungsdatum: 23.09.2007
Beiträge: 802

BeitragVerfasst am: 22.12.2008, 14:34    Titel: Antworten mit Zitat

Hm.. also in VB(A) gibt es eine Funktion namens "TypeName":

Zitat:

Gibt eine Zeichenfolge zurück, die Informationen über eine Variable enthält.

Syntax

TypeName(VarName)

Das erforderliche Argument VarName ist ein Wert vom Typ Variant und enthält eine beliebige Variable, mit Ausnahme von Variablen eines benutzerdefinierten Typs.



Klar, es gibt keinen Datentyp wie "Variant" in FB. Und die Namen von Types gibt das auch nicht aus.
Aber der Zeiger auf eine UDT zeigt ja eh schon auf das erste Element. Und damit hätte man zumindest schon mal den Anfang der Type und den Datentyp des ersten Elementes.
Wenn man den Datentyp des ersten elementes kennt, kann man auch dessen größe abfragen bzw errechnen und dann den zeiger aufs nächste element errechnen. Zumindest wenn der nächste errechnete zeiger noch innerhalb des Speicherbereiches des UDTs liegt.

Eine weiterverfolgung der Kette würde dann geschehen wenn man auf einen Datentyp namens "Any" stößt. Das wäre dann mit einem rekursiven Aufruf der Funktion verbunden die schon erste UDT wegschreiben sollte...
Bei rekursiven Funktionsaufrufen sollte man zwar immer auf Endlosschleifen achten, aber ich denke zumindest das sollte man bei dem erstaufbau der UDT berücksichtigen.
puh.. ich hoffe mir konnte einer folgen... sorry wenn ich mich umständlich ausgedrückt habe!

EDIT:
PS:Mit "Speicherbereichs des UDTs" meine ich die mit LEN( ) ermittelte Größe in Bytes des UDTs
Nach oben
Benutzer-Profile anzeigen Private Nachricht senden
Beiträge der letzten Zeit anzeigen:   
Neues Thema eröffnen   Neue Antwort erstellen    Das deutsche QBasic- und FreeBASIC-Forum Foren-Übersicht -> Allgemeine Fragen zu FreeBASIC. Alle Zeiten sind GMT + 1 Stunde
Seite 1 von 1

 
Gehe zu:  
Du kannst keine Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum nicht antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.

 Impressum :: Datenschutz