Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB

Subject: Re: [boost] Proposal: Monotonic Containers - Comparison with boost::pool, boost::fast_pool and TBB
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-06-22 18:47:30

On Jun 22, 2009, at 6:27 PM, Simonson, Lucanus J wrote:

> Perhaps I missed this part of the discussion, but why is it named  
> monotonic?

The "next allocated object" pointer is always increased,  
monotonically? And, without measures such as the ones you suggested -  
having an allocation counter etc. - it will monotonically lead to a  
crashed system; just kidding, Christian! ;-)

>  I would think something that describes its intended usage would be  
> better.  boost::scratch_memory,

I like the 'scratch' part.

> for example.  Anyone who keeps objects allocated with an allocator  
> called scratch_memory around for the lifetime of his program has  
> some obvious explaining to do.

"But, it is part of Boost, so it must be safe, right?!" does not  
fly? ;-)

>  I also think that a more general interface would be to allow the  
> user to supply and address and size of memory to use as the initial  
> scratch memory with the automatic (on by default) ability to grow  
> beyond that buffer if needed with system allocation on the heap  
> using the chain.  Thread safty should be controlled by a template  
> parameter and enabled by default.

Great input, Luke. The wild ideas and over-simplified implementations  
of Christian's might crystallize with the help of people like you. I  
think I would prefer a solid non-chained realization first, though. If  
that proves stable and intriguing enough, we can consider "chains"?  
Or, is it totally meaningless without chained blocks?

/David