讨论一下VC6中有关VECTOR的代码

[llwwwww]

在vector文件的157行处

void insert(iterator _P, size_type _M, const _Ty& _X)
{if (_End - _Last < _M)
{size_type _N = size() + (_M < size() ? size() : _M);
iterator _S = allocator.allocate(_N, (void *)0);
iterator _Q = _Ucopy(_First, _P, _S);
_Ufill(_Q, _M, _X);
_Ucopy(_P, _Last, _Q + _M);
_Destroy(_First, _Last);
allocator.deallocate(_First, _End - _First);
_End = _S + _N;
_Last = _S + size() + _M;
_First = _S; }
else if (_Last - _P < _M)
{_Ucopy(_P, _Last, _P + _M);
_Ufill(_Last, _M - (_Last - _P), _X);
fill(_P, _Last, _X);
_Last += _M; }
else if (0 < _M)
{_Ucopy(_Last - _M, _Last, _Last);
copy_backward(_P, _Last - _M, _Last);
fill(_P, _P + _M, _X);
_Last += _M; }}



注意第3，4行
它一下就分配现有的两倍内存，
如果现在已经占了可用物理内存的1/3多，这时候需要增长，就会失败
又看了下VC7的代码，改成了分配1。5倍内存，还是只能用到可用物理内存的2/5多

岂不是很不爽！
为什么会做成这样呢

[Kusk]

为了push_back的时候不至于效率太低。如果严格按照分配数等于元素数的话，频繁分配时需要进行
复制操作，在元素多的时候每增加一个元素都要有上千上万甚至更多的元素要复制，效率就十分低
了。但如果预留空间过大，又会造成空间学浪费。根据程序设计中的一些统计，一般预留大小是实际
大小的1.5倍是最佳的平衡点。所以预分配的原因在这里。而空间的损失只是一个常系数而不是更高的
比如平方量级，这点损失是可以接受的。

[CQZE]

一个普通的应用程序不会往vector里扔800MB的东西吧...

[beginnow]

分配内存也要耗煤时间,如果不听的分配必然降低效率,这个问题他们应该考虑啦,可能这样做实利大于弊吧,

[OOPhaisky]

vector内部维护的缓冲区是指数增长的。
楼主不要只考虑物理内存，要考虑虚拟内存，虚拟内存的容量应该远大于物理内存容量。

[睡在床板下_]

分配的 不是物理内存，是虚拟内存。
之后操作系统才将虚拟内存 转为物理内存

[飞哥]

呵呵
楼主觉得vector影响你机器得运行速度了吗？

没有吧
－－－－－－－－－－－－－－－－

如果真得占了那么多估计就挂掉了

虚拟内存

[sinall]

印象中就是按照2的幂增长的。
1）一般情况下不会分配到你说的那么大
2）还要考虑虚存的情况
3）其实1～2倍都可以，1.5应该基本合适
（好像是总结楼上各位的-_-!!!）

[sinall]

补充：
4）此外，这样做是在用最少的次数分配足够的内存和尽量减少内存浪费之间的折衷！

[weijiangshanwww]

根据程序设计中的一些统计，一般预留大小是实际
大小的1.5倍是最佳的平衡点。所以预分配的原因在这里。而空间的损失只是一个常系数而不是更高的
=======================================


赞同

[weijiangshanwww]

LZ所担心的内存不够也是对的，

但是要反过来想下，如果真的有那么大的数据，你还会用VECTOR吗？

那时候要自己设计适合自己的数据结构了！

[突击召唤师]

楼主打算用一个Vector占用系统80%以上的内存？

[taodm]

楼主没看过effective stl吧。
vector是永远不缩小所占内存大小的。
要缩小它只有vector<T>().swap(v);这个办法。

[llwwwww]

想了想也没什么好的改进办法
如果要用到这么多内存的话，周边还要做很多处理
一定要用的，可以预分配一块大内存

[llwwwww]

to OOPhaisky:
我看到它用的都是物理内存

[llwwwww]

还有一个奇怪的是，居然不抛异常，直接内存写错误