IMO the resize/shrink cannot be added via adaptor (unless it is very complex one).
An adaptor that wraps push() and insert() would be considerd too heavy-weight?
It may be possible to design circular_buffer<> as adaptor over [vector | deque | list | slist | shrinkable vector | ...].
The point of NOT adapting a circular_buffer over vector, deque or list is to preserve the fixed time push and pop. It is also useful to automatically overwrite items at the opposite end of the container, to obscure that with resizing semantics seems is undesirable. (In other words, a resizing circular buffer is not consistant with the conventional understanding of what a circular buffer is - correct me if I'm wrong.)
In relation to the previous discussion I thought an alternative container may be a circular_deque that could have the kind of flexibility with resizing that also sounds desirable.
I think this is a tidier solution than complicating the simple concept of a circular_buffer. The question is if there are sufficiently motivated people to develop a circular_deque along side the circular_buffer.
Internally, I thought a circular_deque would be much like a deque up to some optional maximum capacity. To cater for FIFO usage, emptied segments would be recycled at the other end, rather than being deleted and reallocated as needed. So, the allocation/deallocation would be fixed, but deferred until as late as possible. Having the option to flush these blocks of memory waiting to be recycled also seems reasonable. It could be automated via a threshold or heuristic.
Just thoughts.
Nigel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost