64 位文件 API 在每个平台上都不同。
在 Windows 中：_fseeki64
在 linux 中：fseeko
在 freebsd 中：又一个类似的调用...
我怎样才能最有效地使它更方便和便携？有什么有用的例子吗？
问问题
10683 次
5 回答
14
大多数基于 POSIX 的平台都支持“ _FILE_OFFSET_BITS ”预处理器符号。将其设置为64将导致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。其他跨平台库可能提供类似的支持。
于 2009-06-08T16:51:05.700 回答
2
我最好的建议是使用一个已经存在的库来处理这个问题。
一个好的候选人可能正在使用来自GDAL的 CPL 文件库。这为读写、ascii 和二进制访问提供了跨平台的大文件支持。大多数 GDAL 文件格式已经使用它实现，并被广泛使用。
于 2009-06-08T16:35:05.893 回答
0
STLport原生支持 64 位文件大小。另一方面，如果您正在进行密集的磁盘访问，您可能需要使用文件映射：unix上的mmap和 Windows 上的CreateFileMapping。
于 2009-06-08T16:39:11.003 回答
0
我曾经写过一个名为“mfile”的库，它代表“多文件”。问题是我有一个不支持大文件的系统，所以这个库要么使用某些系统上可用的大文件支持，要么处理传递的多个文件，它实际上会连接。
无论如何，它提供了一个类似“文件”的界面，并且运行良好。当我不得不移植到 Windows 时，很容易加入适当的 64 位支持。在 Unix 上，_FILE_OFFSET_BITS 提供了足够的魔力，我不必玩太多游戏就能让它工作。
于 2009-06-08T17:03:49.333 回答
0
编写一个封装文件处理的类，在类中使用条件编译来处理各个平台。
然后，当您需要从程序访问文件时，只需使用该类而不是本机文件处理。
据我所知，在处理大文件时，没有一套通用的可移植文件 I/O 函数。
于 2009-06-08T19:26:11.683 回答