Hi Ross, Agreed. Christian hasn't posted any results for pool_allocator and
fast_pool_allocator either.
I agree that I should do this and I shall. However, it should also be clear that these other allocators are specific to a given type T. Monotonic allocation is available to any type, and from any set of containers, from the same single storage buffer, which can be on the stack, on the heap, or spanning both.
I am also tired of the complete lack of understanding of what is and is not defined in the standard.
I have been completely aware of the standard from the start. My documentation references it, I talk about the issue of non-static data in an allocator there. I have always understood that the standard states that allocators of the same type may be considered isomorphic by a given STL implementation. All I have ever said is that the standard does not say that an allocator may not have non-static data. I'll repeat that, because there seems to be some confusion. All I have ever said is that the standard does not say that an allocator cannot have non-static data. The standard states that a STL implementation may treat allocators of the same type as being all equivalent. I can't help thinking that there is a case here of people cutting off their noses to spite their faces. My benchmarks have shown significant gains in both MSVC and GCC. This is true either for a local storage, or for global storage. So, ignore the local storage for now and consider the case for the static storage. This uses default-constructured monotonic::allocator<T>'s. All such allocators are isomorphic. They have non-static data, sure, but that doesn't matter because a STL implementation can treat all monotonic::allocator<T> as being equivalent, and they can be default-constructed, used, then discarded, repeatedly and safely. I resisted adding a global store because the idea was anathema to me, but now I see that it helps with acceptance. So, you can get an existing data-structure, change it to use monotonic::allocator, recompile and see performance gains. All you need to add is a place to reset the usage. To reject it out of hand seems an act of intentional obtuseness to me. The key aspects of the proposal haven't changed since I first made it: I first added generalised alignment for different types from the same storage, then I added ability for a store to merge into the heap as required, then added a default global storage for use by a default-constructed allocator. These are not sweeping changes. I would consider these a normal part of developing a proposal. Adding a global default storage was absolutely trivial, and it solves any concerns people may've had about allocator equivalence. I should have had this in my proposal from the absolute start. I didn't, because I never had a need for it and in my world globals are bad. Now that it's there, and addresses people's concerns about portability, everyone suddenly loses interest and leaves. Interesting. I was under the impression that proposals were just that, and were expected to be slightly modified as it was exposed to a wider audience. Indeed, isn't that the entire point? There is no argument against the allocator in terms of the standard or use by older STL implementations, because monotonic::allocator<T> can be safely default-constructed, and all instances of default-constructed allocator<T> are exactly identical in every way. To ignore significant gains from very simple code based on personal bias seems silly to me. I will re-write the documentation and base it on just using the single global storage, and make the local-store case secondary. Using default-constructed monotonic::allocator<T>'s (for all T! unlike pool_allocator et al.) with a single global store does not have any lurking issues with portability or unsafe STL implementations, and yet shows significant performance and memory gains out-of-the-box with no other changes required. Sorry to see you go Ross. Regards, Christian.