Man lernt nie aus, bzw. man hat vermutlich nie die Dokumentation vollständig und richtig gelesen.
Wenn man eine Datei nicht sequentiell liest ist es normal Seek, Read/Write in dieser Folge zu nutzen. Order eben SetFilePointer, ReadFile/WriteFile.
In einer StackOverflow Antwort stolperte ich über die Aussage:
you not need use
SetFilePointerEx– this is extra call. use explicit offset inWriteFile/ReadFileinstead
(Rechtschreibung nicht korrigiert).
Aber der Inhalt war für mich neu. Sieh mal an, selbst wen man kein FILE_FLAG_OVERRLAPPED benutzt, kann man die OVERLAPPED Struktur nutzen und die darin vorhandenen Offsets verwenden.
Diese werden sogar netterweise angepasst, nachdem gelesen/geschrieben wurde.
Zitat aus der MSDN (der Text ist gleichlautend für WriteFile):
Considerations for working with synchronous file handles:
- If lpOverlapped is NULL, the read operation starts at the current file position and ReadFile does not return until the operation is complete, and the system updates the file pointer before ReadFile returns.
- If lpOverlapped is not NULL, the read operation starts at the offset that is specified in the OVERLAPPED structure and ReadFile does not return until the read operation is complete. The system updates the OVERLAPPED offset before ReadFile returns.
Ist nett, aber IMO „premature optimization“. Ich würde mal behaupten, dass es in 99,9% aller Fälle keinen signifikanten Performance-Gewinn bringt, den Offset an ReadFile() zu übergeben, anstatt SetFilePointer() zu benutzen. Es macht aber den Code schlechter lesbar, da eine zusätzliche lokale Variable angelegt werden muss (die OFFSET Struktur) und ein 64-bit File Pointer auf die 32-bit Member „Offset“ und „OffsetHigh“ aufgeteilt werden muss. Wenn man relatives Positionieren benötigt, geht das auch nicht mit WriteFile() alleine, da man dann zuvor den aktuellen Offset ermitteln muss. Somit bleibe ich lieber bei SetFilePointer[Ex](), was jeder kennt und bei Lesen meines Codes sofort versteht was da passiert.