Boost logo

Boost :

From: Nigel Stewart (nigels_at_[hidden])
Date: 2003-06-11 09:10:15


Hey, I'm keen on a circular argument... :-)

> - Rename to circular_buffer.

        Agree.

> - Add push_front() and pop_front().
        
        Agree.

> - resize() to behave similarly to vector::resize().

        Agree. That means items will be lost from the
        right end, if necessary. Or, capacity will be
        increased, if necessary.

> - change_capacity() becomes again change_capacity(). I think the name change_capacity
> best reflects what the method really does. The vector::reserve() can only increase the
> capacity, never decrease - which may be confusing. And at last the circular_buffer is
> not vector so it can have different methods from vector.

        set_capacity()?

        Agree. Make it clear in the documentation about
        how change_capacity()/set_capacity() is different to reserve() because of
        the possibility of data being removed to fit the specified
        capacity. A std::vector::reserve call is a hint, while
        a circular_buffer::change_capacity/set_capacity is a hard limit.

> - insert() will always increase the size and possibly can increase the capacity (if not
> sufficient).

        Agree. We should document that circularity (and related constant-time
        guarantees) applies to push/pop, but not insert. (or erase?)

        This strikes me as a good compromise. For one thing, it leaves the door
        open to inserting in a manner that resizes the capacity. (Except for the
        problem that if the buffer is full, every insert will require O(n) time)

        ---

        The thread in relation to automatic resizing has not yet settled,
        but I would suggest going ahead and doing a rev while that one
        settles down.

        ---

        If you think there is a meaningful way that I can help you out over the
        weekend, let me know. (Linux, Cygwin, MSVC 6, 7, Solaris, etc...)

        Regards,

        Nigel Stewart


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk