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