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

Subject: Re: [boost] [utility] new auto_buffer class --- RFC
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-03-02 11:19:34

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)
- 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.