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