Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2009-06-17 17:46:01

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