我已经知道原因了，详情我会发在另一篇
开发平台(Platform): (Ex: VC++, GCC, Linux, ...)
vc++ 14.0
问题(Question)：
原本我都是信奉，如果只是要存放资料，则使用vector
如果有需要放在头，则使用deque
如果有需要在中间插入，则使用forward_list
不过读了GotW #54之后，改变了我一些想法
这边先讲一下我对vector与deque的了解
vector的实作，就是一块连续的内存空间
当空间不够时，会跟内存要求一个更大的空间，并且copy or move原本的资料
优点：
1. 内存空间是连续的，可以很快traverse所有资料
2. 如果已经知道需要多少数量，可以使用reserve，这样不需要再跟内存要求空间
3. 承上，不需要copy or move原本的资料
缺点：
1. 内存的使用比较严苛，因为需要是连续的
2. 如果不知道到时候会需要多少数量，则resize时容易造成内存空间的浪费（当然，
可?
3. 承上，需要copy or move原本的资料
deque的实作，应该如同这张图一样http://i.stack.imgur.com/dbPA6.jpg
因此，deque在增大的时候，会跟内存要求一个固定size的memory
优点：
1. 内存的使用比较不严苛，能更有效利用零碎的空间
2. 在增大的时候，不需要copy or move原本的资料
缺点：
2. traverse比vector慢
3. operator[]比vector慢一点点（这影响应该不大）
接下来就是要探讨的问题
1. 假设只需要存放资料，且不知道会放几笔资料，那应该是deque比vector快（deque不
需?
2. 假设只需要存放资料，且知道会放几笔资料，那应该是deque比vector慢（vector不需
要
但理论只是理论，实际上还是要跑程式才知道，因此我在这边放上我的code
http://ideone.com/LqQbqW
环境：
CPU: intel i7 4930k
OS: windows 7 enterprise sp1, 64 bit
Memory： 64G
Compiler: visual c++ 2015 （vc++ 14.0）
Compiler Option: release, x64, full optimization （/Ox）
输出：
165497（deque）
331978（vector没有reserve）
271584（vector有reserve）
回到问题1，deque的确比vector快（165497<331978），实验数据符合预期结果
回到问题2，？？？
不对阿，我的test_vector2里面有做reserve，test_vector2比test_vector快，这很正常
但是test_vector2不可能比test_deque慢才对啊
如果根据理论分析，vector只要使用reserve，他就不可能输给deque才对
如果问题2的推论是正确的，那为什么实验数据不符合预期结果呢？
补一台
环境：
CPU: intel i7 4700HQ
OS: windows 10 1511, 64 bit
Memory： 4G
Compiler: gcc 5.2.0
Compiler Option: -std=c++14 -O3
输出：
iteration为5000000（原本的1/20），执行5次取平均
1706
1275
1170
（不符合预期结果）
再补一台：
环境：
同上，除了
Compiler: visual c++ 2015 （vc++ 14.0）
Compiler Option: release, x64, full optimization （/Ox）
输出：
iteration为5000000（原本的1/20），执行5次取平均
2814
2664
2420
（不符合预期结果）
难道在资料没有很多的情况下，vector比deque快？
（可是这样很怪，那什么原因会造成资料很多的情况下，vector比deque慢？）
原本是觉得可能跟实作有关，可是最后那两台的数据，都是1>2>3，真是怪了（不过VC的O
x?
code分析：vector的emplace_back（与push_back）的增大
VC++ 14.0：
max(capacity()*1.5,capacity()+1)
gcc 5.2.0：
capacity()+max(capacity(),1)