BlockRead / BlockWrite oder die entsprechenden API's?

[Luckie]

Ich muss Dateien berabeiten, lesen und schreiben. Jetzt gibt es da ja mehrere Möglichkeiten:

1. Die alten pascal Routinen BlockRead, BlockWrite.
2. Die API's ReadFile, WriteFile
   • Selbige direkt ansprechen oder
   • die Delphi Kapselung FileRead, FileWrite.

Ja, was würdet ihr nehmen und warum? Im Moment würde ich das per Würfel entscheiden, aber es muss ja Vor- und Nachteile geben. Und dises wollte ich hie rmal diskutieren.

[Motzi]

Also ich mag die alten Pascal-Routinen nicht.. deswegen arbeite ich immer mit FileStreams (sehr praktisch und leicht mit andren Streams kombinierbar), wenn ich allerdings nonVCL progge (so wie du meistens) greif ich lieber direkt auf die Win32-APIs zurück..!

Warum ich die alten Routinen nicht mag kann ich nicht wirklich sagen - weiß nur noch dass ich sehr schlechte Erfahrungen mit ihnen gemacht hab (hat aber wahrscheinlich an mir gelegen, damals war ich noch ein ganz frischer Frischling )

[OLLI_T]

HY!

@Motzi: TFileStream kapselt auch (nur) die API Funktionen CreateFile, ReadFile, WriteFile ... .

Mich würde mal interessieren, wie die Objektpascal Funktionen auf das Filesystem zugreifen, sprich diese in der Unit System implementiert sind. Kann mit nicht vorstellen, dass Windows direkte Zugriffe auf die Hardware zulässt. Vielleicht hält Borland diese Fkt nur aus "nostalgischen" Gründen am Leben und hat längst die entsprechenden WINAPI Fkt. dahintergeklemmt?!

Könnte mir vorstellen, dass Hagen, NicoDe oder Assa dazu näheres wissen.

Gruss

OLLI

[Luckie]

Danke schon mal für deine Meinung. Allerdings hätte ich schon gern etwas griffigeres. Wenn mich jemand fragt, warum so und nicht so, hätte ich schon gerne eine aussagekräftige Antwort parat.

[Motzi]

Zitat von OLLI_T:

@Motzi: TFileStream kapselt auch (nur) die API Funktionen CreateFile, ReadFile, WriteFile ... .

Ich weiß... aber dennoch ist es wesentlich praktischer - vor allem weil es genauso wie alle andren Streams von der abstrakten Klasse TStream abstammt und daher alle Nachkömmlinge von TStream untereinander kombatibel und sozusagen "austauschbar" sind!

Zitat:

Mich würde mal interessieren, wie die Objektpascal Funktionen auf das Filesystem zugreifen, sprich diese in der Unit System implementiert sind. Kann mit nicht vorstellen, dass Windows direkte Zugriffe auf die Hardware zulässt. Vielleicht hält Borland diese Fkt nur aus "nostalgischen" Gründen am Leben und hat längst die entsprechenden WINAPI Fkt. dahintergeklemmt?!

Diese Funktionen basieren natürlich auch alle nur auf Win-APIs, haben aber ein wesentlich komplexeres System dahinter als die TFileStream-Methoden! Geh einfach mal den entsprechenden Aufrufen im Debugger (mit aktivierten Debug-DCUs) nach...!

[Luckie]

Hier drifftet so etwas vom Thema ab mit euren Streams.

[Luckie]

Dürfte ich es noch mal nach oben holen?

[OLLI_T]

Motzi hat es doch schon auf den Punkt gebracht und ich hab auch gerade in den diversen Assembler Sourcen geschnüffelt. Die guten alten Routinen rufen (natürlich) auch die diversen API Funktion auf. Wäre es anders würde Windows sicherlich ziemlich meckern.

Also würfle ich jetzt für Dich und sage: nimm WINAPI, da Du Deine Software schliesslich auch für Windoof schreibst. Sollte für Dich als NONVCL-Freak doch keine Frage sein.

In der Hoffnung nicht gedriftet zu sein ...

OLLI

[Luckie]

Oh, so war das gemeint? OK. Aber ich nehme die Kapselungen aus der SysUtils. Oder würde etwas dagegensprechen?

[Christian Seehase]

Moin Luckie,

warum nimmst Du dann nicht gleich die zugrundeliegenden API ReadFile, WriteFile usw.
Die Kapselung in den SysUtils, macht ja nichts anderes, als diese Funktionen aufzurufen, und im Fehlerfalle -1 statt false zurückzuliefern.
Das würde Dir dann u.U. die komplette Einbindung der SysUtils ersparen, und das noch ohne sonderlichen Aufwand.