Tatsächlicher Speicherbedarf einfacher Datentypen

Für Fragen zur Programmiersprache auf welcher Lazarus aufbaut
Antworten
AlterMann
Beiträge: 233
Registriert: So 13. Dez 2009, 09:43
OS, Lazarus, FPC: Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 i386-win32-win32/win64
CPU-Target: x86 64Bit
Wohnort: Niederösterreich

Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von AlterMann »

Hallo,

wie ich wahrscheinlich schon erwähnt habe, versuche ich gerade einige ~20Jahre alte Programme in die Gegenwart zu portieren.

Eines davon hat folgende Dateistruktur:

Code: Alles auswählen

type
 
 
 werkzeug = record
      lrn : char;
      negpos : string[3];
      name : string[20];
      comment : string[40];
      identnr : string[10];
      place : string[2];
      number : string[4];
      material : string[5];
      xlong : real;
      zlong : real;
      cutpoint : integer;
      radian : real;
     end;
 
 daten = record
   version : string[4];
   proznu : string[5];
   nummer : string[17];
   name : string[20];
   abstba : real;
   spanndr : integer;
   abstreit : integer;
   reitdruck : integer;
   aussteller : string[15];
   bemerkung : array[1..10] of string[50];
   date : string[10];
   ablage : string[11];
   spannvorr : string[16];
   backen : string[20];
   spanndurm : string[4];
   stkzeit : string[6];
   rstzeit : string[4];
  end;
 
 
 platte = record
           datens : daten;
           tools  : array[1..32] of werkzeug;
          end;


Ich will nix über die Struktur hören, vor 20 Jahren war das eine hervorragende Idee und ist nicht mehr zu ändern. :D

Von dieser Struktur (platte) gab es eine Variable f:file of platte; und wurde genau so auf die Platte geschrieben. So eine Datei hat 4250Byte Länge.
Wen man das nachzählt und den Platzbedarf der Variablen ansieht, stimmt das genau überein.

Jetzt versuchte ich mit genau dieser Struktur eine Datei mit Lazarus zu lesen. Folge: Lazarus wollte übers Dateiende hinaus lesen.
Warum? Tja, weil Die Datentypen wie Integer und real in Lazarus einen anderen Speicherbedarf haben als in Borland Pascal.
Leider gibt es keinen Gleitkommatyp mit 6Byte mehr, also hab ich mir ein kleines Programm in BP (Das läßt sich tatsächlich noch unter XP installieren :mrgreen: )
geschrieben welches rekursiv die paar tausend Dateien einliest und mit dieser Struktur abspeichert:

Code: Alles auswählen

werkzeugneu = record
      lrn : char;
      negpos : string[3];
      name : string[20];
      comment : string[40];
      identnr : string[10];
      place : string[2];
      number : string[4];
      material : string[5];
      xlong : single;
      zlong : single;
      cutpoint : longint;
      radian : single;
     end;
 
 datenneu = record
   version : string[4];
   proznu : string[5];
   nummer : string[17];
   name : string[20];
   abstba : single;
   spanndr : longint;
   abstreit : longint;
   reitdruck : longint;
   aussteller : string[15];
   bemerkung : array[1..10] of string[50];
   date : string[10];
   ablage : string[11];
   spannvorr : string[16];
   backen : string[20];
   spanndurm : string[4];
   stkzeit : string[6];
   rstzeit : string[4];
  end;
 
 
 platteneu = record
           datens : datenneu;
           tools  : array[1..32] of werkzeugneu;
          end;


Man sieht ich habe real mit single und integer mit longint vertauscht, welche in BP und FPC den gleichen Platz brauchen (sollten :x ) (jeweils 4Byte)

Was passiert? Lazarus liest wieder übers Dateiende hinaus.
Speichere ich versuchsweise eine Datei dieser neuen Struktur mit Lazarus, hat diese 4140 Byte auf der Platte (Bei BP 4126)
Woher sind diese 14 Byte?
Hat wer eine Idee?
Zur Not speichere ich halt (mit BP) alle Dateien als Strukturierte TextDatei und lese sie neu ein.
Mir geht's nicht um die genaue Struktur, ich möchte nur die paar tausend Dateien retten (=einlesen können)

Ich weiß, ist lang geworden.
Danke für's Lesen
Christian
Früher war alles besser. Und aus Holz!

lrlr
Beiträge: 127
Registriert: Di 3. Nov 2009, 09:48

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von lrlr »

nach 10 sekunden würd ich sagen
du muss "packed record"
schreiben, sonst macht er ein allign auf z.b. 32bit

den rest schau ich mir an wenn es dann immer noch nicht geht..

AlterMann
Beiträge: 233
Registriert: So 13. Dez 2009, 09:43
OS, Lazarus, FPC: Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 i386-win32-win32/win64
CPU-Target: x86 64Bit
Wohnort: Niederösterreich

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von AlterMann »

Das war's! :P
Vielen Dank.
Christian

mschnell
Beiträge: 3444
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von mschnell »

Schön dass es läuft !

Speichern binär in packed Records ist natürlich nicht "modern" aber sehr effektiv, muss nur natürlih entsprechend dokumentiert werden (Byte-Order etc.), damit irgendjemand mit den Dateien etwas anfangen kann.

Wenn du bessere Laufzeit-Performance brauchst, solltest Du die "packed" Records nach dem Einlesen aus der Datei in nicht "packed" Records kopieren (und vor dem schreiben der Datei umgekehrt). Das kann das Programm erheblich schneller machen.

-Michael

AlterMann
Beiträge: 233
Registriert: So 13. Dez 2009, 09:43
OS, Lazarus, FPC: Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 i386-win32-win32/win64
CPU-Target: x86 64Bit
Wohnort: Niederösterreich

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von AlterMann »

Naja, war ein bißchen voreilig.
Die Dateigröße stimmt jetzt zwar , und er liest es daher auch ein, aber die Struktur stimmt nicht ganz.
Es ist ein paar Zeichen verschoben, d.h. die Längen (vermutlich der Zahlenwerte) stimmen noch nicht ganz.
Da muß ich mir noch was einfallen lassen ...

Mal sehen.


Alles zurück! :D
Funktioniert eh wunderbar, ich hab nur in meiner Schusseligkeit eine nicht konvertierte Datei erwischt. :oops:

Alles bestens.

@Michael
Ja , effektiv ist es schon, aber ich würd's heute trotzdem anders machen.
Man ist halt sehr unflexibel damit. Jede Änderung ist ein Horror.
Und auch wenn mir diese Sichtweise nicht gefällt: Man muß heute nicht mehr jedes Byte umdrehen, Speicherplatz und Rechenzeit sind (meistens) im Überfluß vorhanden.
Früher war alles besser. Und aus Holz!

MmVisual
Beiträge: 1470
Registriert: Fr 10. Okt 2008, 23:54
OS, Lazarus, FPC: Winuxarm (L 3.0 FPC 3.2)
CPU-Target: 32/64Bit

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von MmVisual »

Ja, ich weiß, Du wolltest nichts über die Struktur hören...

Aber wenn man die Datei ohnehin konvertieren muss, dann könnte man die doch auch z.B. in eine XML Datei konvertieren.......

.... Es gibt Komponenten, mit der man eine XML Datei direkt öffnen kann und darin kommt man dann ähnlich wie bei einem TreeView (Baumstruktur) an die Daten.
.... Die Lesen-Routine usw. musst Du sowiso anpassen, die interne Datenstruktur kann ja so bleiben.

Der Vorteil:
- Wenn ein Fehler in der Datei drin wäre, dann könnte man die Datei auch von Hand editieren
- Erweiterungsfähig

Is ja nur ein Gedanke. 8)
EleLa - Elektronik Lagerverwaltung - www.elela.de

AlterMann
Beiträge: 233
Registriert: So 13. Dez 2009, 09:43
OS, Lazarus, FPC: Lazarus 3.0 (rev lazarus_3_0) FPC 3.2.2 i386-win32-win32/win64
CPU-Target: x86 64Bit
Wohnort: Niederösterreich

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von AlterMann »

MmVisual hat geschrieben:Is ja nur ein Gedanke. 8)


Und ja auch kein schlechter ...

Ich hab mir schon ähnliches überlegt, allerdings dachte ich an einen Aufbau wie eine *.ini-Datei.
Allerdings wird es wohl einfacher sein, das in Lazarus zu schreiben als in BP.
Drum werde ich die Daten mit dem BP-Programm konvertieren (geht wohl viel einfacher weil ich da den 6-Byte-Realtyp zur Verfügung habe), in die neue Verson des Programms kommt beim Öffnen eine Abfrage rein, in welcher Form die Daten vorliegen (alt aber konvertiert oder neu) und neu gespeichert wird in dem neuen Format (ini, .. XML) oder was auch immer.

Den Aufbau von XML kenn ich nicht, muß ich mal anschauen.

Grüße
Christian
Früher war alles besser. Und aus Holz!

MmVisual
Beiträge: 1470
Registriert: Fr 10. Okt 2008, 23:54
OS, Lazarus, FPC: Winuxarm (L 3.0 FPC 3.2)
CPU-Target: 32/64Bit

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von MmVisual »

So z.B. sieht XML aus:

Code: Alles auswählen

<?xml version="1.0" encoding="ISO-8859-1"?>
<Programm>
<!-- Definiert den Namen des Namenspace -->
<global name="System">
  <param name="RemoteServerPort" vartype="int32">
     <preset>81</preset>
  </param>
   <param name="RemoteServerIP" vartype="text">
       <preset>192.168.10.100</preset>
  </param>
  <param name="StartServer" vartype="bool">
   <preset>false</preset>
  </param>
</global>
</Programm>

Den gesammten text, was da drin steht kann selbst geschrieben werden, die Namen sind frei erfunden. Hier in dem Beispiel wird ein "vartype" geschrieben, der den Parser fürs lesen die richtige Konvertierung verpasst. "name" ist der Parametername. Man hat doch viele Möglichkeiten.
Wichtig ist dass irgend etwas mit <...> beginnt und mit </...> wieder endet.
Diese Anordnung wäre als TreeView-Darstellung:

Code: Alles auswählen

Programm
 +global
   +param
   | +preset
   +param
     +preset


Ich finde diese Komponente nicht schlecht:
http://www.eonclash.com/ViewProduct.php?ProductID=20
"ECXML Parser". Ich hatte diese früher in Delphi verwendet.

Hier gibts auch ein XML Browser:
http://www.eonclash.com/ViewProduct.php?ProductID=19
EleLa - Elektronik Lagerverwaltung - www.elela.de

Benutzeravatar
theo
Beiträge: 10500
Registriert: Mo 11. Sep 2006, 19:01

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von theo »

AlterMann hat geschrieben:Den Aufbau von XML kenn ich nicht, muß ich mal anschauen.


Die Freepascal Units
DOM, XMLRead, XMLWrite
müssten reichen.
http://wiki.lazarus.freepascal.org/XML_Tutorial/de

_Bernd
Beiträge: 145
Registriert: Di 13. Feb 2007, 11:16

Re: Tatsächlicher Speicherbedarf einfacher Datentypen

Beitrag von _Bernd »

AlterMann hat geschrieben:Drum werde ich die Daten mit dem BP-Programm konvertieren (geht wohl viel einfacher weil ich da den 6-Byte-Realtyp zur Verfügung habe),

Google "freepascal 6 byte real" -> http://www.freepascal.org/docs-html/rtl ... ouble.html

Antworten