ich arbeite an einer Software, die Daten von einer Ausleseeinheit aufnimmt und diese in eine Datei speichert.
Das speichern selbst funktioniert ohne Probleme, ich kann die Dateien am Ende problemlos verarbeiten.
Nun möchte ich aber ein Live-display bauen, dass mir die Daten schon währed des Leseprozesses auch darstellt.
Da die Software objektorientiert aufgebaut ist, kann ich das nicht im gleichen Schritt machen, in dem die Daten gespeichert werden.
Daher gehe ich wie folgt vor:
Von einer Funktion bekomme ich die ich größe der Datei vor dem schreiben neuer Daten (new_file_size in bytes) und nach dem schreiben neuer Daten (old_filesize in bytes).
Diese Daten gebe ich ich meine "display_data" Funktion.
In dieser gehe ich dann wie folgt vor:

unsigned int length=new_file_size-old_file_size; //Neu geschriebene Daten in Bytes

  ifstream input(c_output_filename, ios::in|ios::binary|ios::ate); 
  //oeffenen des gerade geschriebenes Datenfiles, dateipointer ans Ende

  for(int i=0;i<length;i++) input.unget(); // Readoutpointer auf neue Daten stellen

  char * data_buffer;
  data_buffer =new char [length];
  input.read (data_buffer, length); //Store all the data within a buffer
  input.close();

Dann verarbeite ich die Daten.
Allerdings bekomme ich immer 32 mal das gleiche "Ereigniss" angezeigt, d.h. wenn ich die Ereignisse durch nummerieren würde, sähe es wie folgt aus:

32 * Ereignis Nummer 0
32 * Ereignis Nummer 31
32 * Ereignis Nummer 63
usw.

In jedem Schritt des Programmes erhöht sich die Dateigröße um 256 Byte! Diese Versuche ich dann darzustellen...

Wenn ich nach dem Ende des Programmes die geschriebene und geschlossene Datei konvertiere, ist die Ereignissstruktur korrekt, d.h.
1 * Ereginis 0
1 * Ereginis 1
1 * Ereginis 2
usw.

Ich weiß leider nicht mehr woran das liegt! Ein paar Ideen:
--Wenn ich den neuen Stream zum lesen öffne, ist die Datei noch nicht geschlossen,da sie im nächsten Schritt ja wieder erweiter werden soll.

-- Setzte ich den Pointer falsch ???

Ich freue mich über euere Hilfe.
Matthias

Was aber auch noch erwähnenswert ist, ist deine Verwendung von new char[]. Statt

char * data_buffer;
data_buffer =new char [length];
input.read (data_buffer, length); //Store all the data within a buffer
input.close();

solltest du

std::vector<char> data_buffer(length);
input.read (&data_buffer[0], length); //Store all the data within a buffer
input.close();

schreiben.

So sieht nämlich eine Exception-sichere Resourcenverwaltung aus.

input.seekg (-length, ios::end);

allerdings mit ähnlichem Effekt!

Ich hatte diese nicht mit einem "flush" versehen.
Das heißt die Daten waren in einem Zwischenspeicher gespeichert, aber noch nicht in die Datei selbst geschrieben. Der Schreibvorgang wurde alle 32 Events durchführt! Und somit habe ich 32 mal auf das Dateiende zugegriffen, was dann ja immer das gleiche war :-).

Tut mir leid für die Mühen, die ich bereitet habe.... Aber man kann ja auch immer was davon lernen: Nutzt "flush" regelmäßig

Aber man kann ja auch immer was davon lernen: Nutzt "flush" regelmäßig

Die Lehre sollte eher sein: Dateien eignen sich nicht für eine "Live-Übertragung", ich sollte etwas anderes (z.B. Sockets) benutzen. Festplatten sind nun mal sehr langsam, daher ja erst der ganze Aufwand mit dem flush.

Aber man kann ja auch immer was davon lernen: Nutzt "flush" regelmäßig

Nee, das solltest du nicht daraus lernen. flush solltest du bis zuletzt vermeiden. In fast allen Programmen solltest du kein einziges flush (weder direkt noch durch endl) brauchen, höchstens das letzte, automatische flush beim Schließen von Dateien (aka Destruktor des fstream). Das ist natürlich keine absolute Regel, bloß ein Richtfaden. flush ist eine wahnsinnig teure Aktion.

Was du mitnehmen solltest, ist die Lektion aus dem dritten Link in meiner Signatur (dann hätten wir die direkt helfen können) und als allgemeine Stilanweisung: Halte Variablen so lokal wie möglich! Ist es wirklich nötig, dass der Schreibstream zur Zeit des Lesens noch existiert und sogar noch offen ist?

Das Minimalbeispiel mit komplleten Codes hätten auch leider aus drei Klassen bestanden, die einen Tundratreiber (universe chip) und die root Packete nutzen
und wäre einfach zu groß geworden (ca. 5000 Zeilen....).
Daher wollte ich mich auf das wesentliche beschränken, das aber leider nicht ausreichend war

Trotzdem nochmals Danke und Sorry!