导航
  • 主页
  • VC综合技术
  • 互联网技术
  • MFC AppLauncher
  • .NET 技术
  • 界面
  • 进程
  • 算法
  • 硬件/系统
  • 数据库
  • VC++技术资源

关于 VirtualAlloc 申请大虚拟内存问题?

icoder 2010-07-11 10:09:59
请教,现有问题:
在一个应用中要用到4G内存甚至更大,一般的机器不可能满足要求,所以要用到虚拟内存。
问题出现了:
pData = ::VirtualAlloc(NULL, nMemLen*sizeof(CUnit), MEM_RESERVE | MEM_COMMIT, AGE_READWRITE);
nMemLen*sizeof(CUnit)可能达到4-6G的内存,我在后续程序中直接就使用这些内存了,有时会出现莫名其妙的问题。
请教遇到这类问题如何解决???
...全文
232 点赞 收藏 10
写回复
10 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
icoder 2010-07-13
看来只能用内存映射文件来实现了。。。
回复
zhou1xp 2010-07-12
不知道你的需求是怎么样的,内存映射你是可以控制它直接操作硬盘上的文件的,主要是你自己在程序中控制
回复
jogger007 2010-07-12
[Quote=引用 6 楼 hzy694358 的回复:]
nMemLen*sizeof(CUnit)可能达到4-6G的内存,我在后续程序中直接就使用这些内存了,有时会出现莫名其妙的问题。
-----------------------------
貌似楼主的问题是有时会出现问题有时不会出现
也就是说有时能申请成功,
可是这么大的内存在32位下能成功,这个是为什么呢?
[/Quote]
也许就是申请小于4294967295容量的内存的时候可以成功吧。(只是理论上)
回复
hzy694358 2010-07-12
nMemLen*sizeof(CUnit)可能达到4-6G的内存,我在后续程序中直接就使用这些内存了,有时会出现莫名其妙的问题。
-----------------------------
貌似楼主的问题是有时会出现问题有时不会出现
也就是说有时能申请成功,
可是这么大的内存在32位下能成功,这个是为什么呢?

回复
zencher 2010-07-12
[Quote=引用 3 楼 zhou1xp 的回复:]

你申请虚拟内存也是在进程的地址空间申请的啊,32为的进程地址空间可用的也才2G给用户使用啊,建议楼主用内存映射吧
[/Quote]

内存映射??映射到哪里?文件?
内存映射文件的话还不是把一个文件关联到地址空间的某个区域,地址空间依然没有扩大啊,行不通的
回复
BlueMap 2010-07-12
学习。。。
回复
zhou1xp 2010-07-12
你申请虚拟内存也是在进程的地址空间申请的啊,32为的进程地址空间可用的也才2G给用户使用啊,建议楼主用内存映射吧
回复
zencher 2010-07-12
[Quote=引用 1 楼 jingzhongrong 的回复:]

32位程序的地址空间是4G,程序可使用的部分最大也是3G,申请不到那么多的。
[/Quote]

即使是虚拟内存,也是在这个地址空间上分配,所以不可能有4G的。
64位系统的就可以申请更大的内存了,因为64为的地址空间大的不得了。
如果非要在32位下实现超大的使用内存,设计一个多进程通过进程间通讯的程序框架,或许可以实现要求
回复
jingzhongrong 2010-07-12
如果你有足够的物理内存,可以参考Address Windowing Extensions
回复
jingzhongrong 2010-07-11
32位程序的地址空间是4G,程序可使用的部分最大也是3G,申请不到那么多的。
回复
发动态
发帖子
VC/MFC
创建于2007-09-28

1.5w+

社区成员

VC/MFC相关问题讨论
申请成为版主
社区公告

        VC/MFC社区版块或许是CSDN最“古老”的版块了,记忆之中,与CSDN的年龄几乎差不多。随着时间的推移,MFC技术渐渐的偏离了开发主流,若干年之后的今天,当我们面对着微软的这个经典之笔,内心充满着敬意,那些曾经的记忆,可以说代表着二十年前曾经的辉煌……
        向经典致敬,或许是老一代程序员内心里面难以释怀的感受。互联网大行其道的今天,我们期待着MFC技术能够恢复其曾经的辉煌,或许这个期待会永远成为一种“梦想”,或许一切皆有可能……
        我们希望这个版块可以很好的适配Web时代,期待更好的互联网技术能够使得MFC技术框架得以重现活力,……