Re: [boost] [container] varray aka static_vector

Subject: Re: [boost] [container] varray aka static_vector
From: Krzysztof Czainski (1czajnik_at_[hidden])
Date: 2013-02-11 15:32:21

2013/2/11 Andrew Hundt <athundt_at_[hidden]>

> As Adam mentioned in an earlier thread we have renamed static_vector
> to varray to better represent how it works like an array with size
> without requiring the values to be default constructible, and to better
> distinguish it from hybrid_vector.
>
> varray location:
> https://svn.boost.org/svn/boost/sandbox/varray/
>
> Documentation:
> https://svn.boost.org/svn/boost/sandbox/varray/doc/html/index.html
>
> Many thanks for this effort. I'm already using your class (the previous
static_vector at the moment).

>
> One open question is if the 3rd strategy parameter should be public or
> in the detail namespace. Based on some of the feedback we moved the
> strategy from container to container_detail, and made the public
> version varray<typename T, std::size_t N>. However, we wanted to get
> others' thoughts on this change.
>

As I wrote in the previous thread, I'd rather the strategy was public. I
can imagine using varray 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.

> Additionally, should primitives be default initialized with the
> contents of memory like an array or value initialized to 0 like a
> standard container in the constructor, resize(), and emplace_back()?
>

Now that I think of it, I wish there was a way to push an element to the
back of varray without zero-initializing it (for PODs). But I think
emplace_back should be consistent with other containers, so maybe some new
member function can be added for this?

I'd much like those new member functions to be added to other boost
containers too. In particular, I have a use case of a vector, in which
memory is reserved earlier, and then POD elements are pushed to the back in
a time-critical function. Being able to do some uninitialized_push_back or
uninitialized_resize, and then setting contents of elements in place would
be handy.

> Generally, built-in types are initialized when the constructor is
> called explicitly. For example:
>
> int a; // a has the value of underlying memory
> int b = int(); // b has a value of 0
>
> Right now the default behavior of our container is more like a vector
> than an array when creating values using the default ctor. Default
> constructable values are explicitly initialized in the varray ctor,
> resize(), emplace() and emplace_back() functions, even when they are
> trivially constructable. We find this behavior more intuitive and
> therefore we have made it the default. If the performance needs to be
> improved slightly the behavior may be changed or disabled in
> container_detail::varray_traits<V, C, S>.
>

I assume I can't change the Strategy or emplace_back()/resize() behavior
for just one particular varray object, can I?

I mean:

varray<int,5> a;
varray<int,5> b;

I'd like to change the Strategy only for b, can I do that?

Regards,
Kris