On 9 Jun 2009, at 17:14, Christian Schladetsch wrote:
Hi Andrew:
Maybe yes, maybe no. My understanding of the allocators was that they were
originally used to abstract differences in pointer types like __far and __huge pointers. Their usage has become substantially more complex and varied since then.
If STL containers cannot be made by any means to use the stack for storage then we need a new set of containers.
Please, just slow down your posting slightly, and put some more thought in. There is no issue with using stack storage for containers -- I do it regularly. The problem is that std::allocator doesn't work well in extremely memory-limited environments, due to: a) lack of inline expansion b) inability to return maximum amount of memory available. (a) and (b) actually mainly come from the fact that the C memory interfaces don't well support these things. (b) isn't really available, and while you would think realloc would support (a), it doesn't, as there is no way of telling realloc not to move if it can't extend. There have been attempts to correct this error at the C level, which would then hopefully permeate up to allocators. This problem has been previously discussed and solved, on paper at least, see my earlier e-mail today which referenced: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html Implementing this would solve your problems, so any competing suggestion should either build on, or improve, that plan. As I already spent 20 minutes today looking at code you wrote, which you obviously never tested on any compiler, maybe now you could spend a while, read that paper, and see what you think about it. Chris