C ++中的大文件支持
每个平台上的64位文件API都不同。
在windows中： _fseeki64
在linux中： fseeko
在freebsd：另一个类似的电话……
我怎样才能最有效地使它更方便和便携？ 有什么有用的例子吗？
大多数基于POSIX的平台都支持“ _FILE_OFFSET_BITS ”预处理器符号。 将其设置为64将导致off_t类型为64位而不是32位，并且像lseek（）这样的文件操作函数将通过某些预处理器魔术自动支持64位偏移。 从编译时的角度来看，假设您正确使用相关的typedef，以这种方式添加64位文件偏移量支持是相当透明的。 当然，如果您公开使用off_t类型的接口，您的ABI将会改变。 理想情况下，您应该在命令行中定义它，例如：
cxx -D_FILE_OFFSET_BITS=64
确保它适用于您的代码包含的所有操作系统头文件。
遗憾的是，Windows不支持此预处理程序符号，因此您必须自己处理它，或者依赖提供跨平台大文件支持的库。 ACE就是这样一个库（基于POSIX和Windows平台 – 在两种情况下都只定义_FILE_OFFSET_BITS = 64 ）。 我知道Boost.filesystem也支持基于POSIX的平台上的大文件，但我不确定Windows。 其他跨平台库可能提供类似的支持。
我最好的建议是使用一个库来处理已经存在的库。
一个好的候选人可能正在使用GDAL的CPL文件库。 这为ascii和二进制访问提供了对read + write的跨平台大文件支持。 大多数GDAL文件格式都是使用它实现的，并且被广泛使用。
STLport本机支持64位文件大小。 另一方面，如果您正在进行密集的磁盘访问，则可能需要使用文件映射：unix上的mmap和Windows上的CreateFileMapping 。
我写了一个名为’mfile’的库，它代表’多文件’。 问题是我有一个不支持大文件的系统，所以这个库要么使用某些系统上可用的大文件支持，要么处理传递它将虚拟连接的多个文件。
无论如何，它提供了一个类似“FILE”的界面，并且工作得相当好。 当我不得不移植到Windows时，很容易提供适当的64位支持。 在Unix上，_FILE_OFFSET_BITS提供了足够的魔力，我没有玩太多游戏让它工作。
编写一个封装文件处理的类，并在类中使用条件编译来处理每个平台。
然后，当您需要从程序中访问文件时，只需使用类而不是本机文件处理。
据我所知，当涉及大文件处理时，没有一套普遍可移植的文件I / O函数。