Systemnahe Programmierung in Chome Systemnahe Programmierung in C: Vergleich: Destruktive vs. persistente Listen Prof. Dr. Uwe Schmidt FH Wedel

Vergleich: Destruktive vs. persistente Listen

weiter

weiter

Vor- und Nachteile

Definition
destruktiv
Zur Konstruktion neuer Listen werden in vorhandenen Listen einzelne Knoten verändert.
 
Es wird mit Zuweisungen an Komponenten einzelner Knoten gearbeitet
 
...
l -> next = f(...);
return l;
...
gut
Speicherplatz-Effizienz
schlecht
Seiteneffekte
persistent
Zur Konstruktion neuer Listen werden NIE in vorhandenen Listen einzelne Knoten verändert, sondern IMMER nur gelesen und daraus neue Knoten mit den passenden Elementen erzeugt.
 
Es wird NIE mit Zuweisungen an Komponenten einzelner Knoten gearbeitet
 
...
return cons(l->infof(...));
...
schlecht
Speicherplatz-Effizienz
gut
keine Seiteneffekte
weiter
Argumente
destruktiv
Listen als Argumente werden verbraucht.
 
Diese Listen dürfen nicht weiter verwendet werden.
falsch
...
l2 = append(l1x);
...
l3 = append(l1y);
...
 
Listen müssen geklont werden
richtig
...
l2 = append(clone(l1)x);
...
l3 = append(l1y);
...
schlecht
sehr fehleranfällig
persistent
Listen als Argumente werden nur gelesen und behalten somit ihre Werte.
 
Sie dürfen beliebig weiterverwendet werden.
richtig
...
l2 = append(l1x);
...
l3 = append(l1y);
...
gut
keinerlei Fehlerquelle
weiter
Mehrfachverwendung
destruktiv
Listen dürfen auch in einer Operation nie mehrfach verwendet werden.
falsch
...
l2 = concat(l1l1);
...
richtig
...
l2 = concat(clone(l1)l1);
...
schlecht
sehr fehleranfällig
persistent
Listen dürfen beliebig häufig verwendet werden.
richtig
...
l2 = concat(l1concat(l1l1));
...
gut
keinerlei Fehlerquelle
weiter
Sharing
Gemeinsame Nutzung von Teilstrukturen
destruktiv
nicht möglich
falsch
...
l2 = cons(xl1);
l1 = append(l1y);
...
richtig
...
l2 = cons(xclone(l1));
l1 = append(l1y);
...
schlecht
Speicherplatz-Effizienz
persistent
Listen dürfen gemeinsame Teile besitzen
 
...
l2 = cons(xl1);
l1 = append(l1y);
...
gut
keinerlei Fehlerquelle, das Verdoppeln geschieht automatisch
weiter
Speicherverwaltung
destruktiv
händisch: Durch Freigabe aller Knoten
gut
(relativ) einfach
persistent
händisch: Zum Beispiel durch Referenz-Zähler
schlecht
schwierig, aufwändig
gut
Bei Sprachen mit automatischer Speicherverwaltung (Java, Javascript, Python, Ruby, Scala, Haskell, ...) entfällt dieses Problem
weiter
Korrektheit
destruktiv
schlecht
Sehr fehleranfällig durch viele verschiedene Zugriffspfade auf die gleichen Knoten und durch Zuweisungen an Komponenten der Knoten
persistent
gut
Einfach: Es gibt keinen Unterschied zwischen einfachen Werten und Listen.
weiter
merke
Der hier für Listen gemachte Vergleich ist allgemeingültig für alle dynamischen Datenstrukturen, z.B. für Suchbäume, Warteschlangen, Hash-Tabellen, ...

Letzte Änderung: 28.11.2014
© Prof. Dr. Uwe Schmidt
Prof. Dr. Uwe Schmidt FH Wedel