说几个STL的缺点吧，虽然都是在比较极端的情况下出现，但是对于一些大项目还是会遇到的
1. 代码膨胀问题
每一个实例化过的模板类，都会膨胀出一份独立的代码，比如
std::vector<std::string>, std::vector<int>，编译后会产生两份代码，在VC2008下，每份代码大约是3-4kb，这是因为vector比较简单代码少，如果是map则会产生30-50kb的代码，因为map里有个复杂的红黑树。对于数据处理类的代码里一般会定义很多种不同的结构体，不同的结构体放到不同的容器里，就会实例化出很多个类的代码，我见过一个项目里，这样的vector就有数百个。
2. 内存使用效率问题 （以vc++2008为例）
stl在内存使用效率上是比较低效的，比如std::string，它的sizeof大概是28，因为它有一个内置的16字节数组，用来做小字符串优化的，就是说低于16字节的字符串都会至少占用28字节内存，如果刚好17字节字符串，则会占用28字节+额外分配的字符串内存，额外分配的内存是一个堆块，又有很多浪费，相比用一个char *存储字符串大约多占用了一倍内存。
还有map<>，每一个map的node都是一块独立分配的内存，如果是 map<int, int>呢，那就很悲剧了，为了存一个int要消耗几十个字节，很浪费的。
如果元素数量有百万级，那么内存占用就很可观了，这种情况下建议自己实现allocator，做内存池。
3. deep copy问题
让两个容器的实例做赋值操作，看起来就一条语句，实际上容器里的每个元素都执行了一次赋值操作。如果容器里有百万级的数据，那么一个等号就产生了几百万次的构造和析构。
传递参数的时候一定要用 const 引用，赋值可以用 swap代替。
4. 隐式类型转换
比如 有个函数
void doSomething(const std::string &str);
调用的时候
doSomething("hello");
能编译执行，但是会产生一个临时的匿名的std::string实例，把"hello"复制一遍，然后在调用完成后析构掉。如果这个发生在循环体内部有可能影响性能。
以上这些问题，在小程序里或者数据规模不大的时候，比如容器内元素只有几千这个规模，都不是什么大问题，那时开发效率才是重点，但是一旦有大数据stl容器会成为性能瓶颈的。
我并不是主张不用STL，而是要充分了解STL的优缺点，根据应用场景做选择。
