Das ist, wie man Binärdaten schön rausschreiben kann. Also nicht direkt in den Stream, sondern ich benutze einen Binary Reader, um mit dem Stream zu kommunizieren. Eine Maschine, die oben drauf sitzt, fast wie ein Adapter auf dem Stream.

Diese Binary Reader und Binary Reader verstehen die Standard-Datentypen, wandeln die um. Aus diesen Standard-Datentypen nach Binär und umgekehrt. Was dann da drin steht, sind eben Binärdaten. Es gibt noch eine Alternative für den Lückentext 10, wenn ich keine Binärdaten haben will, sondern Klartextdaten.

Dafür gibt es den Stream Reader und Stream Rider. Der ist ein bisschen ungeschickt vielleicht benannt. Ich brauche auch erstmal wieder meinen File Stream. Und jetzt baue ich darüber einen Stream Rider.

Der versteht sich auf Texte. Das ist ein bisschen ungeschickt. Der Binary Reader versteht sich auf Binärdaten. Der Stream Rider versteht sich auf Texte. Ein neuer Stream Rider. Wie hat man denn einen V? Der will natürlich wieder wissen, aus welchem Strom der gebaut werden soll.

Den Stream Rider können Sie auch direkt aus der Fahrtangabe bauen. Ich muss gar nicht erst den File Stream bauen. Ich kann das direkt mit der Fahrtangabe machen. Aber das mache ich jetzt hier mal. Der Ordnung halber tatsächlich mit dem File Stream. Und der Stream Rider versteht sich, wie gesagt, auf Zeichen.

Lesbare Zeichen. Hier können Sie zum Beispiel direkt abrufen, was die Zeichenfolge für die neue Zeile wäre. Oder hier mit Write. Das ist wahrscheinlich am einfachsten wieder mit Write.

Schreibe ich mal irgendetwas raus. Ja, tatsächlich mal. Hier die 42. Dann ist es glaube ich am offensichtlichsten. Das sieht so aus wie eben. Write 42. Und da mache ich hinzu. In der Form. Und nun gucken wir an, was passiert ist. Im Prinzip sieht das ja aus wie oben.

Write 42. Das übersetzt natürlich nicht. Ich sollte das hier gerade mal auskommentieren. Was steht in meinem Stream jetzt drinnen?

42. Lesbar. 42. Überhaupt nicht 42. Nebenbei nicht 42,0. Nicht 42,0. Ganz frech. Es steht 42 drin. Der Streamwriter ist eine Nummer intelligenter. Der nimmt nicht das binäre Muster. Sondern übersetzt das hier wirklich in eine Zeichenkette und schreibt die Zeichenkette.

Das ist wahrscheinlich das, was man ohne weitere Vorbildung erwartet. Dass hier wirklich nackte Zeichenketten drin stehen. Was im Allgemeinen keine so gute Idee ist. Das ist nett. Aus dem Grunde, dass die Datei, die man hier schreibt, sofort lesbar ist.

Aus einem anderen Grunde ist das nicht so schön, wenn Sie tatsächlich solche Zahlen haben wie 3.1415. Ich kann Pi jetzt nicht ausführen. Ich schreibe irgendwas hin. 1, 3, 5, 6, 7, 8, 9, was auch immer. Wenn Sie so eine Double Zahl haben und Sie speichern die Double Zahl binär, sind das 8 Bytes.

Das hatte ich eben erzählt. Ein 64-bitiges Muster. Er speichert 8 Bytes raus. Wenn er diese Zahl dagegen als Klartext speichert, sind es 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 Bytes.

Er braucht ja für jedes Zeichen mindestens 1 Byte. Das frisst gut Speicherplatz. Wenn man kompliziertere Daten hat. Gebäudemodelle, Daten aus der Geografie, irgendwelche Datensammlungen aus Datenbanken.

Dann ist das heikel, die als Textdaten abzuspeichern. Die Größe explodiert, weil jede Nachkommastelle ein einzelnes Zeichen wert. Jede Nachkommastelle frisst ein Byte. Wenn Sie es binär speichern, sind das hier immer 8 Bytes ohne Wenn und Aber. Vielleicht reicht es sogar, wenn Sie es als Float speichern. Wenn Sie es als Float speichern, dann sind es nur in jedem Fall 4 Bytes.

Nie mehr als 4 Bytes. Auch nie weniger als 4 Bytes. Aber erträglich. Problem ist, wenn ich es als Text speichere, dass die Dateigröße explodiert. Ich kann die Datei mit dem Texteditor aufmachen, aber die Größe wird explodieren. Das Simpelste ist, man nimmt die Datei und zippt sie dann.

Dann ist die Welt wieder in Ordnung. Wenn man damit leben kann, dass sie erst zippt werden, dann ist das auch okay. Hier die beiden großen Arten, wie ich mit Streams umgehen kann. Ich kann in Streams einmal binär reinschreiben. Die reine Bitmuster. Und ich kann in Streams Text reinschreiben.

Der Stream-Reader arbeitet natürlich wieder rückwärts. Schreibe ich jetzt nicht hin. Der Stream-Reader arbeitet wieder rückwärts. Ist denn tatsächlich in der Lage, das auch wieder daraus zu poolen? Ich sollte noch kurz zur Allgemeinbildung sagen, wie das in C++ aussieht.

In C++ sieht es ganz anders aus. Wenn Sie sich wundern, ich habe es in ein Skript gedruckt. Wenn Sie sich wundern, wenn Sie sowas sehen, irgendwo der Name eines Datenstroms mir aus dem Stream und dann sowas sehen kleiner kleiner 42, kleiner kleiner 3.14

kleiner kleiner Anführungszeichen abc kleiner kleiner Endel kann man das lesen? kleiner kleiner Endel im Skript steht es ja. Wenn Sie sowas sehen, wissen Sie, oh, das ist C++. Die Erfinder von C++ haben sich eine

eigene Schreibweise für die Streams ausgedacht. Was hier gemeint ist, ist theStream.Write42 theStream.Write314 theStream.Writeabc theStream.WriteEndline oder Nextline oder wie man das dann auch immer nennen würde.

Das sah mal aus wie eine gute Idee. In Java und C-Sharp wird es nicht mehr so geschrieben, für anscheinend keine so gute Idee ist, loszuschreiben. Dieser Operator hier, kleiner kleiner, das ist eigentlich in den ganzen C-Sprachen ein Operator, um Bitweise zu verschieben. Der ist für Datenströme in C++

anders verwendet, auf diese Weise. Nicht wundern, wenn Sie sowas sehen, wissen Sie, oh ja, das ist echt C++. Und gemeint ist, die 42 ausgeben, dann die 314 ausgeben, dann abc ausgeben und dann endline ausgeben. Dasselbe gibt es auch umgekehrt, mit Varianten hinten, das heißt dann jeweils einlesen. Und Skripteit ist mal ausbuchstabiert.

Also das nur als Background, wenn Sie das mal sehen. Auch das sind Datenströme, dasselbe Ding, nur etwas schräg geschrieben mit diesen Pfeilen. Kleiner kleiner, größer größer.