Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Christian Holmquist (c.holmquist_at_[hidden])
Date: 2011-10-11 20:25:27

On 11 October 2011 19:11, Jeffrey Lee Hellrung, Jr. <
jeffrey.hellrung_at_[hidden]> wrote:

> On Tue, Oct 11, 2011 at 4:55 PM, Christian Holmquist
> <c.holmquist_at_[hidden]>wrote:
>
> > On 11 October 2011 14:41, Andrew Hundt <athundt_at_[hidden]> wrote:
> >
> > > On Tue, Oct 11, 2011 at 12:41 PM, Eelis van der Weegen <
> eelis_at_[hidden]
> > > >wrote:
> > >
> > > > On 2011-10-09 19:59, Andrew Hundt wrote:
> > > >
> > > >> Anyone still have additional thoughts or interest in this?
> > > >>
> > > >
> > > > I think this type of container is very useful, and would love to see
> > one
> > > in
> > > > Boost.  Should you decide to submit your library for review, I will
> > > > definitely review it. :)
> > > >
> > > > Eelis
> > > >
> > > >
> > > Great, thank you! I'm looking at the submission process page at:
> > >
> > >
> > I second that. I've been using boost::array<> with a sentinel value to
> > indicate end, which is both ugly and requires length to be 1 longer than
> > needed.
> > boost::container::static_vector seems like a good addition, maybe it can
> be
> > reviewed for inclusion in upcoming Boost.Container.
> >
> > FWIW, I think that static_vector should throw std::bad_alloc if it runs
> out
> > of space, to mimic an out of memory situation for ordinary containers.
> > (Consider an algorithm that needs temporary storage, and user passes a
> > static_vector as tmp storage policy. The algorithm might be designed to
> > handle std::bad_alloc in some way).
> >
>
> I'm presently against any throwing behavior related to resizing of a
> StaticVector/static_vector, since one can usually easily check the relevant
> preconditions themselves.  Just assert.  For those who want defined
> behavior
>
It's not always you know that you're dealing with a static_vector, but just
some code that expects push_back() to work or throw.

> in resize overflow (or underflow) situations, I'd say derive or wrap.  Some
> kind of policy template parameter could be possible, but right now it feels
> like that's an unnecessary complication on an otherwise relatively simple
> data structure.
>

A lot of things get simplified when ignoring correctness.

- Christian