Boost logo

Boost :

Subject: Re: [boost] Interest in Boost.Array companion: StaticVector - A statically allocated fixed capacity vector
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-08-14 17:35:04


[rearranging; note that bottom- or inline-posting is preferred, see
http://www.boost.org/community/policy.html#quoting]

On Sun, Aug 14, 2011 at 10:09 AM, Andrew Hundt <athundt_at_[hidden]> wrote:

> On Sun, Aug 14, 2011 at 5:59 AM, Joel falcou <joel.falcou_at_[hidden]>
> wrote:
>
> > On 14/08/11 11:55, Andrew Hundt wrote:
> >
> >> Sample Code:
> >> StaticVector<std::size_t,3> three;
> >> three.push_back(5);
> >> three.push_back(2); // size: 2 capacity: 3
> >> three.push_back(3);
> >>
> >> three.push_back(1); // throws std::out_of_range exception indicating
> the
> >> capacity has been exceeded
> >>
> >
> > Can't this just be done using Boost.Container or any stateful allcoator
> > aware container implementation with a stateful allocator holding the
> static
> > allocated block of memory ?
>

True, but then the type would be syntactically uglier, you'd like have 3
extra pointers (begin, end_size, end_capacity, right?) or so of overhead,
and there may be missed optimization opportunities if the compiler can't
determine that, e.g., this and begin always point to the same byte in memory
(this is just speculation).

It seems I missed the container review, it does look like that would
> suffice. The simplicity of the StaticVector implementation may still make
> it
> useful for cases where all you really need are a simple array and a size,
> in
> the same way that boost.array is useful for an array alone. However, its
> entirely possible that StaticVector is now redundant, and that's why I'm
> asking if there is any interest. :-)
>
> I've also tried to come up with a better name for it, but that is the best
> I
> could think of. Any better naming suggestions around?
>

I've used a similar object that I called bounded_vector, so I think there
are definitely use cases for this.

- Jeff


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