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

Reply via email to