Ich will nicht, dass:
1. Meine Anwender auch nur die Möglichkeit haben die Dateien zu editieren.
2. Dritte in die Dateien reinschauen können.
3. Kompatibilität zu Vorgänger-Versionen herzustellen ist.
4. --- Punkt gestrichen ---
Daher werden alle Daten-Dateien Verschlüsselt, mir jeweils anderer Reihenfolge pro Programmstart gespeichert,
jeweils mit anderem Offset versehen, die Verschlüsselung ändert sich per Zufall usw. Querbeziehungen stellen eine
Manipulation fest, redundante Speicherung verhindert Datenverlust. Und alles was mir in den letzten 31 Jahren noch so eingefallen ist.
[/
OT]
Ist das dein Ernst? Wo sind die Ironie-Tags?
Zitat:
PS: Unnötig zu erwähnen, dass es nix schnelleres gibt als ein Blockread... Wenn die Datensatzlängen dann noch glatte Sektorgrößen/Binärlängen haben...Und der Lesepuffer so viele Daten aufnehmen kann wie die Festplatte in einer Umdrehung
lesen kann....
Ich weiss nicht, in welchem Jahrhundert Du lebst, aber erstens gibt es schnelleres als ein Blockread (ReadFileGather, MMF usw.), zweitens macht Dir deine Win-
API mit ihrer Systempage einen Strich durch die Rechnung und drittens kräht im 21.Jahrhundert kein Hahn mehr primär nach Performance.
Wartbarkeit, Erweiterbarkeit, Robustheit sind die Schlagworte. Wenn das alles gewährleistet ist, kannst Du über Performance nachdenken. Oder wenn Du ein RDBMS schreibst, oder einen Datenlogger, von mir aus.
Die gängigen und modernen Dateiformate und Bibliotheksfunktionen sind eh schnell genug und fast immer wartet die Anwendung auf den Anwender und nicht umgekehrt. Ich mache mir jedenfalls keine Gedanken mehr über Probleme, die vor 30 Jahren schon gelöst wurden.
Zitat:
PPS: Achja, dass waren noch Zeiten, als man den Floppy-Controller und die DMA noch per
ASM angesprochen hat.
Gott-Sei-Dank sind die vorbei und man muss nicht mehr in der Buddelkiste Häuschen bauen sondern kann mit ausgereiften Werkzeugen Städte konzipieren und errichten (lassen).
Wenn mir ein altes 'File-Of-Record' über den Weg läuft, welches ich lesen muss, dann drücke ich jedes Mal die Daumen, ob die Feldausrichtung der Recordelemente immer noch genau so ist, wie damals. Das Problem hat man ja -nebenbei bemerkt- nicht nur bei Dateien, sondern leider werden auch viele Daten so verschickt.
Ich gehe mittlerweile so vor, das ich Element für Element einzeln aus dem Stream fische. So kann ich padding Bytes, Endianverknurpselungen oder sonstige exotische Dateitypen individuell abfangen.
Wenn ich Objekte serialisiere (was einem File-Of-Record ähnlich ist), dann bekommen meine Objekte eine Versionsnummer. Die steht in jedem 'Record' als erstes. Anhand dieser Nummer kann ich dann entscheiden, wie ich vorgehe und welche Eigenschaften in welcher Reihenfolge gelesen werden.
XML finde ich persönlich grauslich, aber nur, weil die Datei 'ein wenig' größer wird, als beabsichtigt. Ansonsten ist es idiotensicher und eignet sich auch zum Austausch mit Daten aus der inneren Mongolei. Hier ist JSON für mich geeigneter, weil es genauso idiotensicher ist, aber eben kompakter.
Um die Frage des TE zu beantworten: Man darf, wenn man muss, aber man sollte nicht, wenn man die Wahl hat.