Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-06-09 15:45:33

On 9 Jun 2009, at 20:40, Ross Levine wrote:

> Chris, it clearly states in your paper that you referenced, in  
> section 4.1,
> that he is assuming the erasure of the equal-allocator assumption.  
> Checking
> the C++ standard, section 20.1.6, you will quickly see that the
> equal-allocator assumption is still in place under the current  
> standard.
> Thus the techniques mentioned in that paper are non-portable. I will  
> be the
> first to say that this is stupid and makes lots of problems, but it  
> is there
> and there's nothing we can do.
>

True, but that paper seriously breaks things anyway -- it adds more  
methods to allocator (via a versioning method) which must then be used  
by the containers to get any benefit. By the time you have required  
those non-standards things, it's probably not unreasonable to also  
require proper support for stateful allocators.

Chris

> Perhaps having a boost.config macro could solve the problem. If a  
> particular
> implementation enforces the equal allocator assumption, a template
> specialization for std::vector<T, boost::monotonic_allocator<T> >  
> (and list,
> deque, etc) could be defined.
>
> On Tue, Jun 9, 2009 at 12:52 PM, Christopher Jefferson <
> chris_at_[hidden]> wrote:
>
>>
>> On 9 Jun 2009, at 17:14, Christian Schladetsch wrote:
>>
>> Hi Andrew:
>>>
>>> Maybe yes, maybe no. My understanding of the allocators was that  
>>> they were
>>>
>>>> originally used to abstract differences in pointer types like  
>>>> __far and
>>>> __huge pointers. Their usage has become substantially more  
>>>> complex and
>>>> varied since then.
>>>>
>>>
>>>
>>>
>>> If STL containers cannot be made by any means to use the stack for  
>>> storage
>>> then we need a new set of containers.
>>>
>>
>> Please, just slow down your posting slightly, and put some more  
>> thought in.
>>
>> There is no issue with using stack storage for containers -- I do it
>> regularly. The problem is that std::allocator doesn't work well in  
>> extremely
>> memory-limited environments, due to:
>>
>> a) lack of inline expansion
>> b) inability to return maximum amount of memory available.
>>
>> (a) and (b) actually mainly come from the fact that the C memory  
>> interfaces
>> don't well support these things. (b) isn't really available, and  
>> while you
>> would think realloc would support (a), it doesn't, as there is no  
>> way of
>> telling realloc not to move if it can't extend. There have been  
>> attempts to
>> correct this error at the C level, which would then hopefully  
>> permeate up to
>> allocators.
>>
>> This problem has been previously discussed and solved, on paper at  
>> least,
>> see my earlier e-mail today which referenced:
>>
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2045.html
>>
>> Implementing this would solve your problems, so any competing  
>> suggestion
>> should either build on, or improve, that plan.
>>
>> As I already spent 20 minutes today looking at code you wrote,  
>> which you
>> obviously never tested on any compiler, maybe now you could spend a  
>> while,
>> read that paper, and see what you think about it.
>>
>> Chris
>>
>>
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost