Hi Mr Simonson. About the utility of vector_tree. Some years ago I worked in a atomic simulation of silicon doping for the semiconductor design. The silicon to high temperature produce spontaneous “defects” in the atomic structure of the silicon. This depend of the temperature, and the probability of the kind of “defect”. The "defects" makes the silicon semiconductor Each time interval we throw a buch of electrons with high energy against the silicon. When the electron crash with the defect, depending of the energy of the electron , and the angle, can occur several things. The defect absorb the electron, , the electron break the defect and generate new defects, others rebound and in others destroy the defect. The positions are continuously changing. You can't sort by any parameter. I had the defects in a vector_tree, and divide the number of defects between the number or cores of the machine, assign to each core their defects and begin to process. The possibility of insert and delete in any position at log(N), was very useful. As you can imagine, the complexity was bigger than the described here, but I thing this is not place for to show a detailed specification of the project. The word is bigger than I had seen, even bigger than I can imagine. And every day I learn and expect new things for to be astonished. It is the same since 28 years ago, when I began to program in C, and 22 years ago when I began to program in C++ ( I bought the TurboC++ 1.0 in 1990, 1 week after it appear in the market ). About the standard: The history shows than the facts change the rules. According to the standard, to use std::sort and binary search over a vector_tree is wrong. But it run well, and the time spent in sort a million elements is similar to insert the elements in a std::set. I don't question the standard. I only show the facts. It run well, and, the most important for me, I thing it can be useful to the programmers community. This is my motivation for to do this. The standard can be expanded, relaxed, modified or nothing. What do you suggest me ? Delete the library, because it is not according to the standard, or perhaps , think about what need to be changed, or modified in the standard for to adapt to the new reality. The new C++11 appear when the library was finished, and I was writing the documentation and checking the code. The new standard is very good, but have a problem, if you do according the last standard , you are discarding the majority of the C++ compilers used actually. My idea is to use the new features of C++11, but trying to maintain the compatibility with older compilers, at least until the new standard was widespread. About the statefull allocators. I have my own idea, but I need to study more in order to have a founded opinion. The suballocator can be transformed in statefull allocators with a few changes in the actual code, but I need to think about the utility and the problems related. Regards Francisco Tapia