[boost] Re: circular_buffer and unused space overhead

From: Nigel Stewart (nigels_at_[hidden])
Date: 2003-07-28 08:04:17

> 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