Re: [boost] Proposal: Monotonic Containers

Subject: Re: [boost] Proposal: Monotonic Containers
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-16 11:17:25

On Jun 16, 2009, at 8:46 AM, Frank Mori Hess wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Tuesday 16 June 2009, Christian Schladetsch wrote:
>> In truth, this is a non-issue. The code you presented broke the  
>> standard;
>> monotonic allocator didn't. Allocators are indeed allowed to have
>> non-static members.
>
> I hate to contradict your prejudices, but std c++03 containers are not
> required by the standard to support allocators which contain state,  
> as has
> been noted several times already in this thread.

DISCLAIMER: this post of mine might sound a bit harsh, but since  
Christian's "proposal revision factory" basically has occupied this  
list for a while, I think it is fair.

It is interesting how much leeway this group gives to a quite immature  
"proposal" and its stream of quick fixes. No offense to Christian, I  
truly enjoy the energy he brings and there is something to the  
*overall idea* of having a limited pre-allocated block used by  
multiple containers, including lists and trees.

I am quite certain that a proper proposal for such an idea will not  
come from Christian himself, due to a lack of experience with advanced  
C++ issues and a bit of a focus problem. It might come from Thorsten,  
though.

BUT, the truth is that as soon as we enter real high-performance use  
cases, we often end up with one of two scenarios:

1. We know how many elements we will deal with at most, and they are  
not too many; we can then reserve the space in a vector.

2. There are many elements or they come and go during runtime. We then  
need a proper allocator, which also can deallocate.

It is not clear how frequent, or important, the cases not covered by  
these two scenarios are, and in some of the space between #1 and #2,  
we can use Thorsten's auto_buffer. The only cases that are really  
palatable to the idea behind Christian's stream of proposals is that  
of multiple small, and pretty fixed, containers being used for an  
extended time in a high performance scenario. I am not sure this case  
is that common.

I.e., it might very well be that even the *overall idea* concerns a  
non-problem in real life.

Questions to the populace here: Do we see an light in the tunnel here,  
i.e., is this problem trying to be solved a problem? Do we want  
Christian to refine his ideas further? Do we want him to do it  
interactively on the list?

/David