Re: [boost] [utility] new auto_buffer class --- RFC

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2009-03-02 12:08:04

Mathias Gaunard skrev:
> Thorsten Ottosen wrote:
>> Mathias Gaunard skrev:
>>> Thorsten Ottosen wrote:
>>>
>>>> Well, AFAIK, they are very similar. You set the capacity once when 
>>>> you initialize am object:
>>>>
>>>>   boost::auto_buffer<T> buffer( get_max_capacity_from_somewhere() );
>>>>
>>>> isn't that exactly what you do with VLAs?
>>>
>>> With VLAs, the buffer is on the stack whatever the capacity. With 
>>> auto_buffer, the buffer is on the stack only if the capacity is 
>>> smaller than N (which you define to be 256 by default).
>>
>> Yes. I'm talking about the conceptual behavior of the class.
> 
> A VLA is a fixed-size array whose size is determined at runtime.
> It is conceptually more like scoped_array than auto_buffer.
> 
> Basically, we have all these array type possibilities (fixed capacity 
> implies dynamic size):
> - fixed compile-time size: C/C++ arrays or boost::array
> - fixed runtime size: VLAs or scoped_array (we need better, something 
> without pointers in the interface and with copy semantics)
> - fixed compile-time capacity: nothing (something would be useful)

Let's call this static_auto_buffer.

> - fixed runtime capacity: auto_buffer
> - variable capacity (necessarily at runtime): std::vector
> 
> All of these situations have different strategies for memory management:
> - allocate everything within the object itself, that is to say on the 
> execution stack (only possible for fixed compile-time size or capacity)
> - allocate everything in an area external to the object, such as was is 
> colloquially known as the heap, and reference that area (possible for 
> every situation, and may be a better strategy even if the first is 
> possible)
> - allocate the buffer in the object itself if the buffer is smaller than 
> a certain fixed compile-time size, and use an external memory source 
> otherwise. That technique is typically known as Small Buffer 
> Optimization (possible for every situation)
> 
> So auto_buffer is a fixed runtime capacity array which uses the third 
> strategy.
> 
> I suggest all array type possibilities be implemented with all memory 
> management strategies.
> Which means obviously making some kind of policy-based design, with SBO 
> something independent that you can plug into auto_buffer.
> 
> I have worked on some kind of allocator interface that allows SBO, if 
> there is interest.

Thanks for the detailed analysis.

The question is if there is much need for all these permutations. I do 
use static_auto_buffer, but the overhead induced by auto_buffer is
very small (1 word + a few instructions in initialization).

I question the using auto_buffer without an internal stack buffer. This
is more or less the whole reason for its existance.

-Thorsten