[boost] Re: circular_buffer and unused space overhead

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2003-07-28 14:21:50

"Nigel Stewart" <nigels_at_[hidden]> wrote in message
news:bg36n1$1eg$1_at_main.gmane.org...
>> > 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?
>
I think it is pretty heavyweight, but maybe there's some misunderstanding.

> 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.)
>
My feeling is that with optional auto-resize feature circular_buffer<> may
hit the sweet spot of being good enough for 80% apps. The auto-resize would
kick in only when user explicitly asked for it.

The fixed push/pop times and optimal memory use would be guarantied if
things are going in normal, expected way.

When buffer needs to get resized it is likely result of exceptional
situation somewhere else and the resize overhead may be insignificant at
this point.

Primitive type elements may be detected and memcpy() solution used to
decrease resize overhead here.

> 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 was thinking about circular_bitbuffer<>, space efficient bool container.
Boolean values are quite common output of sensors.

/Pavel