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
