是否可以在2GB +文件上创建较小的内存映射视图?

时间:2011-02-24 20:35:58

标签: c++ windows linux

我为Windows和Linux编写了一个C ++类,它为任意大小为n的文件创建了一个内存映射视图。类构造函数can be seen here的代码。我目前正在Windows 32位XP上测试代码。

我发现文件大小为0&lt; n <= 1.7GB,构造函数返回一个指向内存映射视图的有效指针。但是,对于文件大小&gt; = 2 GB,MapViewOfFile返回NULL值和错误代码8,“没有足够的存储空间可用于处理此命令”。显然,Windows无法在此过程中找到大小为2 GB的可用地址空间。

因此,我可能需要修改类构造函数以创建一组较小的内存映射视图,总计&gt; = 2GB字节&amp;&amp; &LT; 2 ^ 32 - 1个字节。另一个要求是在每个较小的内存映射视图和进程的地址空间中随机访问的地址之间创建映射。

以前,我使用以下代码进行随机访问:

char* KeyArray;

try {
    mmapFile = new cMemoryMappedFile(n);
}
catch (cException e)
{
    throw;
}

KeyArray = (char *)(mmapFile->GetPointer());
KeyArray[i] = ...

我应该如何修改类来处理这些要求?

5 个答案:

答案 0 :(得分:3)

使用重新制作可以实现您想要的效果,看看它是如何在boost.iostreams here中完成的。

答案 1 :(得分:3)

在32位操作系统上,只有 2GB(或3GB,有一些调整)的用户进程空间。期。这是一个很难的限制,并且创建许多较小映射的数量都无法实现。您需要移动映射以访问文件的不同部分。但它仍然比寻找,阅读和写作更快。

答案 2 :(得分:2)

这不起作用。您根本无法在32位Windows上使用所有4 GiB的地址空间。重新设计对数组的访问权限,只映射大文件的小视图。

答案 3 :(得分:2)

我看不到你的pastebin链接,但我可以建议一个带有c ++类声明的简单解决方案。我认为实施应该从评论中明显:

class ShiftingMemMap
{
public:
    // constructs a dynamically shifting memory map of a file...
    ShiftingMemMap ( const char* fileName, size_t view_size = 4096 );

    // retrieve/set a byte at the given file offset. If the offset is not currently in-view,
    // shift the view to encompass the offset. The reference should not be stored for later
    // access because the view may need to shift again...
    byte& operator [] ( unsigned int_64_t offset );

private:
    int_64_t current_offset;
    size_t current_size;
};

所有这一切,您可以编写一个返回文件多个视图的类,以便以后保存参考,同时编辑文件的不同部分,而不必反复移动视图。

class MemMap
{
public:
    MemMap ( const char* filename );

    shared_ptr<MemMapView> View ( unsigned int_64_t offset, size_t size = 4096 );
};

class MemMapView
{
public:
    char& operator[] ( size_t offset );
};

答案 4 :(得分:0)

是的,可以为Windows,Solaris Unix,Linux编写C ++类,为任意大小为n的文件创建内存映射视图。我们刚刚完成了两个版本的类,一个使用STL,另一个是我老板写的不使用STL。在32位Windows,Linux,Solaris Unix上,当内存分配大小为1千兆字节或更多时,两个版本都比使用堆更好。         这两个版本都兼容64位Windows,Linux,Solaris Unix。         如果您想了解更多相关信息,请发送电子邮件至frankchang91@gmail.com。美国马萨诸塞州。这两个版本是独立设计的,可能成为美国专利申请数据融合的一部分。