Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at