AMDG Christian Schladetsch wrote:
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.
Regardless, we already have a complete set of STL containers in Interprocess to work around this and other allocator issues in the current standard. http://tinyurl.com/kq3rs2
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.
According to the standard, all instances of monotonic::allocator should compare equal because since deallocate is a no-op, any allocator can be used to deallocate memory allocated by any other allocator. Therefore, allocator equality is a non-issue.
I will re-write the documentation and base it on just using the single global storage, and make the local-store case secondary.
Allowing both local storage and a single global storage in the same allocator type seems like a bad idea to me. If you don't do any locking, then the global storage will not play well with threads. If you do lock, then you will introduce extra overhead for local storage. If you lock only for global storage, then the semantics may be confusing.
Using default-constructed monotonic::allocator<T>'s (for all T! unlike pool_allocator et al.)
boost::pool_allocator always uses global storage. rebind etc. work just fine. In Christ, Steven Watanabe