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
I suggest all array type possibilities be implemented with all memory
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk