Boost logo

Boost :

Subject: Re: [boost] Proposal: Monotonic Containers
From: Christian Schladetsch (christian.schladetsch_at_[hidden])
Date: 2009-06-09 10:11:47


allocator<T>::rebind<U>::type

On Wed, Jun 10, 2009 at 2: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
>


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk