From practical point of view, adding auto-resize to circular_buffer is
easier than creating new container.
Well from a code comprehension view, is it helpful that
a particular container may or may not be in a
auto-resizing mode?
We could well built a container that
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.
I suppose my resistance to that is partly aestetic.
Having a container that is
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.
Does a circular_deque sound like the right solution
to your particular application, rather than a
vector-like
Nigel Stewart [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Wouldn't it be better to use smaller internal memory block initially and
resize it only when demand goes up?
That's a good point, but it certainly complicates both the interface
and the semantics of the container.
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
Nigel Stewart [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
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
Wouldn't it be better to use smaller internal memory block initially and
resize it only when demand goes up?
Pavel,
That's a good point, but it certainly complicates both the interface
and the semantics of the container. Could this style of circular
buffer be an adaptor, or perhaps a policy
