Me personally, my biggest complaint with the STL containers is that you don't get direct control over when they call malloc or free.
Which standard library containers are you concerned about doing allocations beyond those allocations where they use the given Allocator instance and invoke its allocate() member function?
My biggest peeve is std::vector. I absolutely hate that it can ever allocate new storage on its own. In my preferred STL2 design, a vector would only ever occupy its capacity which is given to it at the time of construction. It cannot change its capacity at all. You the programmer can, of course, create a new vector of larger capacity and have all the contents from the old vector moved/copied into the new vector. All the remaining STL2 containers are then built in layers atop this STL2 vector, muxed in with Ranges and Views. BTW STL1 containers don't go away. They're still available for when you don't care and just need something quick and dirty. And for legacy code of course. You can see some of my STL2 container ideas in AFIO v2 where memory mapped files are "malloc" and `afio::algorithm::mapped_view<T>` is a typed view of some mapped file storage. I haven't implemented `afio::algorithm::vector<T>` yet, but it's on the plan. One of the super cool things with this design is constant time vector extensions when the type has a trivial move and copy constructor because we simply map the underlying file storage to a new address. No memory copying needed. The other super cool thing is sparse storage, so you can allocate trillion element vectors without issue on any system. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/