Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: Ross Levine (ross.levine_at_[hidden])
Date: 2009-06-09 15:40:20

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.

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
>