shrink_to_fit跟swap哪个才能真正的释放掉内存

shrink_to_fit和swap哪个才能真正的释放掉内存？
我们知道swap可通过调用复制构造函数与容器交换，来达到释放内存的目的，这是切实可行的，而且实际检测确实释放了内存，然后新标准，也就是C++11也出了一个专用函数shrink_to_fit，用它来释放vector和deque容器中释放不掉的内存，但是这个函数有点搞笑，它并不保证一定会释放掉多余的内存，而且看编译器的脸色，也就是说它只是提出请求，如果请求被采纳，那么内存被释放，如果请求不被采纳，那么不好意思，不能释放。
这样就有一个问题了，既然你不能释放掉内存，那么我不是还得使用原来的swap吗？因此我的问题是，shrink_to_fit和swap哪个才能真正的释放掉内存？
------解决方案--------------------

引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:

shrink_to_fit才是设计来替代swap释放内存的问题的。应该尽量用shrink_to_fit
shrink_to_fit会在几种典型情况下放弃重分配：
元素类型不支持无异常移动。使用拷贝完成内存重分配期间某个元素构造抛出异常。此时函数回滚容器到调用前状态，错误不返回。
重分配新位置需要的内存失败。
capacity()和size()相等（这种是典型情况，表示不需要重分配）。

shrink_to_fit也有失败的时候？

只是说放弃重分配，不算“失败”

放弃重分配是什么意思？函数回滚容器到调用前状态，错误不返回又是什么意思？使用拷贝完成内存重分配期间某个元素构造抛出异常又是什么意思？

这些都是异常安全方面的内容
放弃重分配，就是说恢复到shrink_to_fit调用以前的状态，表现的就好像这个函数根本没调用过。
构造函数表示错误状态只能通过抛异常来实现，因为构造函数没有返回值，在内层函数构造的时候一般也没有办法向通过返回值的方法向外层返回错误。至于抛不抛异常、什么时候会抛，要看元素类是怎么设计的。
回滚就是说，比如一个vector之类的容器，里面已经有10个元素，而capacity()为11，这时候调用shrink_to_fit，这个函数先分配了新的内存块刚好能容纳10个元素；接下来逐一将元素从旧的地址构造到这个新内存块的对应位置。而因为元素类不支持无异常的移动构造而使vector决定用拷贝构造的方式构造新元素。然后，比如当拷贝第4个元素的时候元素构造函数抛出异常，这时候该怎么办？vector接下来会把刚才构造成功的3个元素析构掉，然后删除新分配的那块内存后从shrink_to_fit返回。这样vector的capacity()仍旧是11而原来的10个元素都继续保持有效。这就跟没调用过shrink_to_fit一样。