C++中的大文件支持

Question

64位文件API在每個平臺上都不相同。

在Windows中：_fseeki64
在Linux中：fseeko
在freebsd：另一個類似的呼籲......

我怎樣才能最有效地使其更加方便和便攜？有沒有什麼有用的例子？

Answer 1

大多數基於POSIX的平臺都支持「_FILE_OFFSET_BITS」預處理器符號。將其設置爲將導致off_t類型爲64位而不是32位，文件操作函數如lseek（）將通過某種預處理器魔術自動支持64位偏移量。從編譯時間的角度來看，以這種方式添加64位文件偏移量支持是相當透明的，假設您正確使用相關的typedef。當然，如果您公開使用off_t類型的接口，您的ABI將會發生變化。理想情況下，您應該在命令行上定義它，例如：

cxx -D_FILE_OFFSET_BITS=64 

確保它適用於您的代碼包含的所有操作系統標頭。

不幸的是，Windows不支持此預處理器符號，因此您必須自己處理它，或者依賴提供跨平臺大文件支持的庫。 ACE是一個這樣的庫（基於POSIX和Windows平臺 - 只需在兩種情況下定義_FILE_OFFSET_BITS = 64）。我知道Boost.filesystem也支持基於POSIX的平臺上的大文件，但我不確定Windows。其他跨平臺的庫可能提供類似的支持。

Answer 2

我最好的建議是使用庫來處理這個已經存在的庫。

一個很好的候選人可能會使用GDAL的CPL文件庫。這爲ascii和二進制訪問提供了對讀寫的跨平臺大文件支持。大部分的GDAL文件格式都是用它來實現的，並且被廣泛使用。

Answer 3

STLport本機支持64位文件大小。另一方面，如果您正在進行密集磁盤訪問，則可能需要在UNIX上使用文件映射：mmap，在Windows上使用CreateFileMapping。

Answer 4

我寫了一個名爲'mfile'的庫，它代表'多文件'。問題在於我有一個不支持大文件的系統，所以這個庫會使用某些系統上可用的largefile支持，或者處理傳遞多個文件，這些文件幾乎要連接起來。

無論如何，它提供了一個類似FILE的界面，並且工作得很好。當我不得不移植到Windows時，很容易放入適當的64位支持。在Unix上，_FILE_OFFSET_BITS提供了足夠的魔力，我不必爲其工作而玩太多遊戲。

Answer 5

編寫一個封裝文件處理的類，並在類中使用條件編譯來處理每個平臺。

然後，只需使用該類而不是本機文件處理，當您需要從程序訪問文件時。

據我所知，當涉及大文件處理時，沒有一套通用的可移植文件I/O函數。