Re: [boost] [container] static_vector: fixed capacity vector update

Subject: Re: [boost] [container] static_vector: fixed capacity vector update
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-02-01 03:07:03

2013/2/1 Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]>

> 2013/1/31 Krzysztof Czainski <1czajnik_at_[hidden]>:
> > 2013/1/17 Andrew Hundt <athundt_at_[hidden]>
> >
> > Hello,
> > Thanks for working on static_vector, I'm already using it.
> >
> > Everything works, with a little fix I needed. Here's the problem
> > (disclamer: tested with a more complicated example, not the one below):
> >
> > static_vector<int,3> v;
> > v.emplace_back(); // compile time error
> >
> > My fix is adding an overload for static_vector_detail::construct, patch
> > attached.
>
> Ok, thanks. It's fixed now.
>

Thanks.

Furthermore I'd like to share some news.
>
> We've decided to slightly change the character of this container and
> highlight it's connection with array. Therefore we changed it's name
> to varray (variable-size array). The implementation with "Strategy"
> template parameter was moved to container_detail namespace. Exposed
> class takes 2 template parameters, exactly like boost::array does.
>
> boost::container::varray<T, N> va;
>
> It may be found here:
> http://svn.boost.org/svn/boost/sandbox/varray/

For the record, I'd rather the strategy was public. I can imagine using
static_vector in a few places in the same project with different strategies:
1) In most places I'd probably use the default strategy.
2) At the time of optimizations I might want to disable all checking
(asserts) only for one specific use. In practice we don't create separate
debug/release builds, since we need the debug version to be fast enough
anyway, and in some places this means disabling asserts.
3) In some cases temporary cases I might want logic errors to be thrown, so
that the crash of an early version of one module doesn't crash the whole
system.

Also, I prefer the name static_vector, but that's just my personal approach
- maybe I just got used to it ;-)

Although, now that I think of 0-arg emplace_back(), that doesn't
value-initialize types with a trivial constructor - does vector work like
this too? If not, then it's a good argument towards the name varray ;-)

Cheers,
Kris