Re: [boost] [circular_buffer] some comments and suggestions

From: Neil Groves (neil_at_[hidden])
Date: 2008-01-21 07:55:05

I am happy that you are not suggesting allocation in the push operation.

I think that requiring a call to reserve() is surprising behaviour since one
would have to call reserve() for the container to work. This is inconsistent
with the standard containers in a different manner. I have always wanted my
circular_buffer uses to be allocated at full size. Perhaps the default
behaviour could remain the same but an additional constructor could be
provided to avoid allocation during construction?

Neil Groves

On Jan 21, 2008 11:58 AM, Thorsten Ottosen <thorsten.ottosen_at_[hidden]>
wrote:

> Neil Groves skrev:
> > Hi!
> >
> > I agree with most of the comments from Thorsten. I do however disagree
> with
> > point 1. The allocation in the constructor allows zero allocation in the
> > subsequent push calls. Often a circular_buffer is used in tight loops of
> > push operations. I would not want the additional overhead of the
> allocation
> > check. With types with no-throw guarantee copy constructors I also would
> not
> > want the additional possibility of an exception thrown from the push
> > operation. I would not use this class if the push operation had this
> > additional overhead.
>
> I don't see how you get into the troubles you mention. I don't want
> push_back() to regrow, but neither does it have to: simply can reserve()
> prior to use. Otherwise you get whetever push_back() does on an empty
> buffer (either we say as a precondition that it is not empty, or we
> allow it to do nothing at all).
>
> -Thorsten
>
> > On Jan 21, 2008 10:40 AM, Thorsten Ottosen <thorsten.ottosen_at_[hidden]>
> > wrote:
> >
> >> Hi Jan,
> >>
> >> #1
> >> I was browsing through the docs in trunk. First I noticed that the
> >> default constructor has the follwoing postcondition:
> >>
> >>   capacity() == max_size() && size() == 0
> >>
> >> I find that somewhat unfortunate that it allocates a huge amount of
> >> memory. It seems to me that it is too easy to do that by coincidence.
> >> The usual rule for std containers is to never allocate by default and
> >> anticipate a call to reserve() or the first element. It also seems to
> me
> >> that this will create problems when the container is used in containers
> >> that might use default construction.
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>