Datentypen warum referenzdatentypen

[knowledge]

hi,

bei primitiven datentypen (int usw.) wird der wert ja direkt in der variablen gespeichert, wohingegen bei referenzdatentypen eine adresse drinsteht, die auf das entsprechende objekt zeigt.

wieso macht man das und speichert das entsprechende objekt nicht auch so ab, ohne den zwischenweg über eine referenz?
habe gelesen das man referenzen nutzt weil das speicherplatz spart und schneller ist als wenn man immer eine vollständige kopie erzeugen würde. ist das speicher/geschwindigkeitsproblem in der heutigen zeit wirklich so von relevanz? speicher gibts doch eigentlich genug und soviel langsamer wird das doch nicht, wenn man was kopiert.

wozu also referenzdatentypen?

 

[Landei]

hi,

bei primitiven datentypen (int usw.) wird der wert ja direkt in der variablen gespeichert, wohingegen bei referenzdatentypen eine adresse drinsteht, die auf das entsprechende objekt zeigt.

Das ist richtig.

wieso macht man das und speichert das entsprechende objekt nicht auch so ab, ohne den zwischenweg über eine referenz?

Manche Sprachen bieten beide Möglichkeiten, etwa C und C++ (und stiften damit mächtig Verwirrung). Sprachen ganz ohne Referenzen/Pointer werden in der Mainstram-Programmierung kaum verwendet.

habe gelesen das man referenzen nutzt weil das speicherplatz spart und schneller ist als wenn man immer eine vollständige kopie erzeugen würde.

In C++ kann man sich entscheiden, ob man eine Kopie oder nur einen Zeiger mitliefert. Aber selbst wenn man eine Kopie macht, wird diese ja in der Regel am Ende der Methode wieder freigegeben, also ist der Unterschied nicht so riesengroß. Natürlich hat man schneller einen Zeiger umgebogen als ein ganzes Objekt kopiert.

ist das speicher/geschwindigkeitsproblem in der heutigen zeit wirklich so von relevanz? speicher gibts doch eigentlich genug und soviel langsamer wird das doch nicht, wenn man was kopiert.

wozu also referenzdatentypen?

Ich denke Speicher und Geschwindigkeit spielen eine Rolle, der Hauptgrund ist aber etwas anderes:

Eine Referenzvariable ist nicht der "Name eines Speicherbereichs" sondern der "Name eines Zeigers auf einen Speicherbereich", also ein indirekteres Konzept. Damit lassen sich Strukturen verwirklichen, die mit direkten Variablen nicht zu realisieren wären. z.B. ein Graph, der aus Kanten und Knoten besteht:

class Edge {
   Vertex v1;
   Vertex v2;
}

class Vertex {
   List<Edge> edges;
}

Das funktioniert nur, weil Edge nicht "wirklich" zwei Vertizes enthält (und Vertex keine Liste von Edges), sondern nur Referenzen/Zeiger darauf. Der Hauptgrund ist also, dass Referenzen durch die zusätzliche "Indirektheit" mehr Freiheitsgrade lassen und damit flexibler sind.

 

[SlaterB]

und allein zum Speicher,
stell dir folgende simple Methode vor

byte[] getBigger(byte[] b, byte[] b2) {
  return b.length > b2.length? b : b2;
}

soll die für jeden winzigen Vergleich MB-große Arrays kopieren? da wird jedes System langsam, besonders wenn tausendfach aufgerufen

 

[Wortraum]

ist das speicher/geschwindigkeitsproblem in der heutigen zeit wirklich so von relevanz? speicher gibts doch eigentlich genug und soviel langsamer wird das doch nicht, wenn man was kopiert.

Natürlich ist das relevant. Nicht nur ist es völlig unnötig, statt einem Gigabyte zwei Gigabyte zu verbrauchen, nur weil man beispielsweise eine zweite Liste mit Objekten verwendet, die bereits in der ersten Liste vorhanden sind; es ist außerdem völliger Mumpitz, da jede Änderung an einem Objekt dann auch bei seiner Kopie stattfinden müßte. Diese Synchronisation zwänge selbst starke Rechner schnell in die Knie.

Stelle Dir mal einen Server vor, der Produkte eines Internet‐Ladens verwaltet, und nun sind da ein paar hundert Benutzer auf diesem Server. Im Hintergrund werden die Produkte gepflegt, aktualisiert, von Kunden angeschaut, sortiert, gefiltert, gesucht, in den Warenkorb gelegt, bestellt, gedruckt, gespeichert, bewertet – und für jede Aktion sollen ständig Kopien der Objekte angelegt werden? Wo willst Du denn den RAM dafür auftreiben?

Oder ein anderes einfaches Beispiel: doppelt verkettete Listen. Ich wüßte spontan nicht einmal, wie das ohne die Referenzen aussehen könnte.

Da man bei objektorientierter Programmierung doch recht häufig etwas mit Objekten macht, sollte jegliche Arbeit mit Objekten natürlich schnell und effizient sein. Sicherlich: ob ein Auto nun 5 oder 50 Liter Benzin verbraucht, 200km/h oder 2km/h fährt, das ist egal, wenn es nur darum geht, zum Ziel zu kommen – das schafft man in dem einen Fall wie im anderen. Es geht, aber eigentlich ist es absolut unbrauchbar, und es bedeutet einen extremen Aufwand für die Synchronisation der Zustände von den Objektkopien.

Anbei bemerkt ein wichtiger Unterschied zwischen Objekten und Elementartypen: Objekte haben einen Zustand, der sich in der Regel ändern kann; jeder Variablenänderung in einem Objekt bedeutet eine Zustandänderung. Elementartypen haben keinen Zustand, sie sind einfach nur ein Wert. Eine 5 ist eine 5, 2.45f ist 2.45f und true ist true. Diese Werte sind weder größer als eine Referenz, noch können Inkonsistenten entstehen, wenn man diese kopiert.

 

[SlaterB]

Stelle Dir mal einen Server vor, der Produkte eines Internet‐Ladens verwaltet, und nun sind da ein paar hundert Benutzer auf diesem Server. Im Hintergrund werden die Produkte gepflegt, aktualisiert, von Kunden angeschaut, sortiert, gefiltert, gesucht, in den Warenkorb gelegt, bestellt, gedruckt, gespeichert, bewertet – und für jede Aktion sollen ständig Kopien der Objekte angelegt werden? Wo willst Du denn den RAM dafür auftreiben?

das allerdings ist meiner Vorstellung nach eher ein schlechtes Beispiel ,
die Produkte sind doch in der DB, jeder User bzw. gar jeder Request mit einer eigenen DB-Session, alles neu laden,
Änderungen isoliert bis zum Commit usw.

man kann sich natürlich einen Read-only Cache vorstellen

 

[knowledge]

Hallo,

Danke für die bisherigen Antworten. Im Wesentlichen kann man also festhalten:

1. Ohne Referenzdatentypen würden sich bestimmte Datenstrukturen wie Listen Bäume usw. überhaupt nicht realisieren lassen.
2. Würde mit Kopien gearbeitet werden müssten diese unter Umständen konsistent gehalten werden was wieder Zeit kostet und die ganze Sache verlangsamt

Die Sache mit der Zeit ist mir prinzipiell klar, das Bsp. mit dem Vergleichen von byte Arrays war auch sehr schön. Über was für Performanceprobleme reden wir hier? D.h. wieviel langsamer würde eine solche Lösung sein, wenn man nicht nur mit Referenzen arbeiten würde?

 

[Final_Striker]

D.h. wieviel langsamer würde eine solche Lösung sein, wenn man nicht nur mit Referenzen arbeiten würde?

ausprobieren ;-)

 

[Wortraum]

@SlaterB:
> man kann sich natürlich einen Read-only Cache vorstellen
Genau.

D.h. wieviel langsamer würde eine solche Lösung sein, wenn man nicht nur mit Referenzen arbeiten würde?

Ich tippe auf absolut unbrauchbar, aber wegen der Konsistenz und Synchronisierung ist das ohnehin mehr unmöglich als alles andere.

 

[knowledge]

Danke für die zahlreichen Wortmeldungen. Ich denke jetzt hab ich es verstanden. Also würde man es anders machen verschwendet man unnötig Speicher, manche sehr wichtige Datenstrukturen (z.B. Baum) wären überhaupt nicht realisierbar. Bedingt durch den Speicherverbrauch und ggf. notwendiger Konsistenzsicherung würde die Lösung dann auch noch sehr langsam werden.

Hätte noch jemand ein griffiges Bsp. wo die Kopien alle konsistent gehalten werden müssten?


Danke