Std::deque does not release memory until program exits

On linux, std::deque does not release memory until program exits. The complete code is below. Any help will be greatly appreciated!

#include <deque>
#include <vector>
#include <string>
#include <iostream>
#include <boost/shared_ptr.hpp>
#include <queue>
#include <list>
#include <cstdio>
#include <cstdlib>

typedef  boost::shared_ptr<std::vector<int> > VecPtr;
typedef  std::deque< VecPtr  > QueueType;

 char buf[1024];
 char line[1024];

 int main()
 {

  {

    int v=0;
    QueueType  deq;
    for(int i=0; i<30;++i)
    for(int j=0; j<1000;++j)
    for(int k=0;k<1000;++k)
    {
       VecPtr p( new std::vector<int>);
       deq.push_back(p);
    }

    std::cout<<"Done with increasing deq:deq size="<<deq.size()<<std::end开发者_JAVA百科l;
    sleep(20);

    std::cout<<"start decreasing deq size"<<std::endl;
    while(deq.size()>0)
    {
      deq.pop_front();
    }
    std::cout<<"done with decreasing deq size,deq size="<<deq.size()<<std::endl;
  }
  std::cin.getline(line,sizeof(line));
  return 0;
}

That is correct, pop_front() does not deallocate storage that was allocated by push_back() If you want to deallocate it before the program ends, you can end the lifetime of the object. If you want to deallocate it before the lifetime of the object ends, consider using a "shrink-to-fit" idiom for C++ container classes.

QueueType().swap (deq); // C++98
deq.shrink_to_fit(); // C++11

Copying a response from MSalters on How to release memory from std::deque? (thanks to Emile Cormier for the link).

"std::deque will return memory to its allocator. Often this allocator won't return the memory to the OS. In such cases, it appears as if memory is not "released". Good memory leak detectors will be satisfied as soon as memory is returned to the allocator, and understand that not all memory is released by free()."

So even when it frees memory, it doesn't really free memory. This is easily regarded as unreasonable behavior, unless all allocation in the program is performed by STL; rather narcissistic of the library. Therefore consider overriding the allocators for any memory-intensive data structures, to improve control. Others have found the STL allocator system lacking as well - see the EASTL project from Electronic Arts.