Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Ross Levine (ross.levine_at_[hidden])
Date: 2009-06-09 10:43:46

Most of the messages here ignore an important detail, quoted from Scott
Meyer's Effective STL, item 10:

"[T]he Standard says that an implementation of the STL is permitted to
assume that all allocator objects of the same type are equivalent and always
compare equal... It means that portable allocator objects — allocators that
will function correctly under different STL implementations — may not have
state. Let's be explicit about this: it means that *portable allocators may
not have any nonstatic data members*, at least not any that affect their
behavior. None. Nada. That means, for example, you can't have one
SpecialAllocator<int> that allocates from one heap and a different
SpecialAllocator<int> that allocates from a different heap. Such allocators
wouldn't be equivalent, and STL implementations exist where attempts to use
both allocators could lead to corrupt runtime data structures."

To summarize, std::vector<T, monotonic_allocator<T> > won't work if each
vector gets a specific buffer, because another vector could possibly use
that buffer instead! Thus a custom version of each container is REQUIRED
unless there's a boost.test macro BOOST_STL_ALLOCATOR_EQUIVALENCE or
something like that.

On Tue, Jun 9, 2009 at 10:03 AM, <joaquin_at_[hidden]> wrote:

> Stewart, Robert escribió:
>
>> joaquin_at_[hidden] wrote:
>> On Tuesday, June 09, 2009 9:34 AM
>>
>>
>>> Stewart, Robert escribió:
>>>
>>>
>>>> There's a problem with using an allocator for the node based
>>>> containers: they use the allocator to allocate the elements
>>>> but not the nodes.  That implies free store (de)allocations
>>>> for the nodes which is contrary to the intended purpose of
>>>> this proposal.
>>>>
>>>>
>>> Umm, I beg to differ. If we have a node-based container
>>>
>>>  xxx<T,...,custom_allocator<T> >
>>>
>>> and node<T> is the internal node type, the container is required
>>> to do the allocation using an allocator of type
>>>
>>>  custom_allocator<T>::rebind<node<T> >::other.
>>>
>>> The container is not allowed to do any kind of allocation using
>>> other means than the custom_allocator<X> family of allocators.
>>>
>>>
>>
>> If custom_allocator<node<T> > is not specialized to do the same as
>> custom_allocator<T>, or to use the same memory pool, then it
>> doesn't fit the proposal.
>>
>
> Point conceded, but how would you do otherwise? Specifying a custom
> allocator is
> your only way to affect the container's allocation behavior. Seems like
> you're
> implying that the container wrapping approach is in some way more powerful
> than
> directly specifying the custom allocator, which is not.
>
> Your only chance to solve the problem you mention is to make
> custom_allocator<node_type<T> > use the same memory pool. There's a way to
> do this.
> If you construct the container with
>
>  custom_allocator<T> a;
>  xxx<T,...,custom_allocator<T> > x(a);
>
> then xxx will use an object of type custom_allocator<node<T> > for its
> allocation
> needs, which perforce will be an object differnt to the allocator a you've
> passed;
> but the container is required to construct this internal allocator as a
> copy of a:
>
>  // inside xxx implementation
>  custom_allocator<node<T> > internal_a(a);
>
> So you can use this knowledge to pass info around, for instance on the
> memory
> pool to be used.
>
>
> Joaquín M López Muñoz
> Telefónica, Investigación y Desarrollo
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>