klima: Überarbeitung der Ein- und Ausgabe



  • Hi(gh)!

    Um das Löschen und nachträgliche Verändern einzelner Datensätze (und, längerfristig, auch das Hinzufügen, Verändern oder Löschen von Feldern) zu vereinfachen, will ich die Ein- und Ausgabeprozedur umstellen: bei Programmstart soll der gesamte jeweils aktuelle Datenbestand in ein Array vom Typ "Klimadatensatz":

    typedef struct 
    {
      char station[30];
      char land[30];
      char region[30];
      char latitude[11];
      char longitude[12];
      short int hoehe;
      short int cperiod_first;
      short int cperiod_last;
      float temperatur[DIM];
      float niederschlag[DIM];
      float tempmittel;
      float niedsumme;
      char formula[4];
      char quelle[60];
    } Klimadatensatz;
    
    

    geladen werden. Dazu muss natürlich vorher mit malloc() die ensprechende Menge Speicherplatz (Anzahl Datensätze * sizeof(Klimadatensatz)) bereitgestellt werden; ich stelle es mir so vor, dass in einem ersten Lese-Durchgang die Anzahl der Datensätze ermittelt wird und dann in einem zweiten Durchgang die Datensätze eingelesen werden - oder kann ich den Speicher auch schon in der ersten Lese-Schleife mit jedem weiteren eingelesenen Datensatz kontinuerlich erweitern? Wie mache ich das innerhalb einer Funktion?

    Bis bald im Khyberspace!

    Yadgar


  • Mod

    Dynamisches Mitwachsen der Datenstruktur ist, wie man das macht. Üblicherweise, indem man stets um einen gewissen multiplikativen(!) Faktor vergrößert. Also zum Beispiel, erst einmal nur 1, braucht man mehr 2, brauch man mehr 4, braucht man mehr 8, etc.

    Wobei 2 laut einiger Experten angeblich ein denkbar ungünstiger Faktor wäre, aber da auch keiner wirklich weiß, was warum besser wäre, nehmen die meisten Leute doch 2 🙂



  • @seppj Naja, das Argument gegen 2 ist ja, dass nie genau der Speicher wiederverwendet werden kann, der von den vorherigen Vergrößerungen freigegeben wurde, denn 4 > 2+1, 8 > 4+2+1 usw. Ich fand https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md dazu ganz spannend.



  • Also wenn man sich kurz die fest vordefinierten Arrays in der Struktur ansieht, die immer gleich viel Speicher unabhängig vom Füllstand belegen. Da ist die Überlegung ob man nun x oder 2x Speicher belegt, erstmal Zeitverschwendung - denn auch die struct hat schon in der Größenordnung Verschwendung eingebaut.



  • @tggc ??? Diese Überlegung ist doch völlig unabhängig von der konkret verwendeten Struktur, d.h. es geht doch nicht um Verschwendung innerhalb der struct!

    Und wo ist da ne große Verschwendung eingebaut? Wenn du die char-Arrays meinst: bedenke, dass ein char* auch 8 Bytes lang ist (zumindest auf 64 bit), insgesamt werden dann mindestens strlen + 1 + 8 Bytes benötigt. Gut, die lon und lat könnte man als float speichern und da was einsparen. Aber das hat doch mit dem Vergrößerungsfaktor nichts zu tun.



  • Warum sollte man hier überhaupt dynamisch re-allozieren?
    Einfach die Anzahl der Datensätze am Anfang der Datei abspeichern...



  • @th69 sagte in klima: Überarbeitung der Ein- und Ausgabe:

    Warum sollte man hier überhaupt dynamisch re-allozieren?
    Einfach die Anzahl der Datensätze am Anfang der Datei abspeichern...

    Warum? Na, weil doch schließlich auch weitere Datensätze eingegeben werden sollen!


  • Mod

    @th69 sagte in klima: Überarbeitung der Ein- und Ausgabe:

    Warum sollte man hier überhaupt dynamisch re-allozieren?
    Einfach die Anzahl der Datensätze am Anfang der Datei abspeichern...

    Diese Art Metadaten sind erfahrungsgemäß immer frickelig. Das macht das Dateiformat sehr anfällig für falsche Schreib- und Lesevorgänge, da der Inhalt mit den Metadaten konsistent gehalten werden muss. Und am Ende muss das Leseprogramm doch auf den Fall vorbereitet sein, dass die Metadaten nicht stimmen.

    Die Methode mit der automatischen Vergrößerung ist ein wichtiges Standardpattern, das universell auf eine Vielzahl von Problemen anwendbar ist, auch weit jenseits von Datendateien. Zudem kostet es relativ wenig Aufwand für den Programmierer. Wenn es irgendeine andere Sprache außer C wäre, wäre der Aufwand sogar komplett 0.


Log in to reply