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.