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

Subject: Re: [boost] [container] static_vector: fixed capacity vector update
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2013-01-21 19:23:55

On Sun, Jan 20, 2013 at 12:59 PM, Andrew Hundt <athundt_at_[hidden]> wrote:

> On Fri, Jan 18, 2013 at 4:17 PM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:
> >
> > This is encouraging!
>
> Thanks!
>
> > Great, seems almost simple enough. I say "almost" because, IMHO, we
> > shouldn't try *too* hard to make static_vector a drop-in replacement for
> > vector. Make the interface common where it makes sense, but reserve and
> > shrink_to_fit shouldn't be part of the interface. It would just confuse
> me
> > if I saw a reserve or shrink_to_fit method call on a static_vector in
> real
> > code.
>
> This may make sense to do. It could alternately be #ifdef'd out in some
> BOOST_CONTAINER_VECTOR_COMPATIBILITY mode that enables shrink_to_fit()
> for those that are clients of template code they cant change, but could
> specify the container type. Perhaps that isn't worthwhile either and
> users should just remove their shrink_to_fit calls if they want to use
> static_vector.
>

I would argue for the latter. As I think Dave expressed, I don't see this
as a general drop-in replacement for std::vector (and I realize it was
never necessarily marketed as such), rather its a drop-in replacement for
certain use cases that presently might use std::vector but probably
shouldn't.

> > Changes:
> > >    - C++11 support
> >
> > Please elaborate.
>
> It supports all the C++11 member functions, such as move semantics and
> emplace() that boost::container::vector supports. Allocators are the
> obvious exception in addition to some runtime performance degradation
> in cases such as swap() because a simple pointer swap is not possible.
>
> In case you were concerned, everything is also set up for C++03.
>

Good. I'd encourage making it Boost.Move-compatible as well.

> The documentation is not the prettiest right now, which is fine
>
> I agree that the documentation wording, formatting, and examples still
> need improvement.
>
> > one key omission is a Strategy concept specification (at least, I didn't
> see
> > one).
>
> The Strategy concept is defined in the code using Boost.concept_check.
> Adding it to the documentation depends on how the discussion
> immediately below and in Q4 of my Q&A goes since it wouldn't make
> sense to document the strategy if it is not part of the public API.
>
> > Also, I'm not 100% sold on the Strategy template parameter. I think
> there's
> > something to be said for simplicity, and the simplest implementation
> would
> > have just 2 template parameters and assert on any bounds violations; if
> you
> > want to throw, use, say, a free function push_back_and_throw_on_error. At
> > least, that's what I'd say is an alternative design.
>
> I concur, while I'm fairly happy with the current code I too am not
> 100% sold on the Strategy. I wrote more detail in Q4 of the Q&A
> section of my original post. The proposed alternative is putting the
> current version into the detail namespace and defining one or more
> publicly available interfaces using partial specializations in which
> the strategy is fully defined.
>

Or just offer one variant, period, which asserts on bounds errors. I'd lean
toward that but I guess I might have a different philosophy on throwing
than others (I'd say, by default, only provide a throwing interface when
preconditions can't be reasonable checked by the calling code).

> >   - bounds checks are asserts by default but can be switched to
> exceptions
> >
> > Is this true for static_vector::at as well, or does that throw regardless
> > as with std::vector?
>
> static_vector::at() throws in the same manner as
> boost::container::vector::at() by default. It is also possible to
> disable exceptions so in that case there is an assert() when indexed
> out of bounds. Perhaps the case where exceptions are disabled should
> use BOOST_VERIFY so it triggers in release mode too for at()?
>

Eh, I don't really care; does anyone actually use std::vector::at in
practice? Serious question (I haven't seen it yet, but I haven't been doing
software development professionally for very long, either).

> >    - memory is uninitialized until objects are inserted
> >
> > Hmmm...this is a change?! I would think this is a correctness requirement
> :/
>
> The original version was boost::array with size so the behavior was
> much more understandable. I agree that the new behavior is much better
> and that's why it has been changed. :-)
>

Make sense.

[...]

> > >     - optimizations based on type traits
> >
> > Please elaborate.
>
[...]

> The type traits optimizations are the same ones provided by
> boost::container::vector, such as using memcpy/memmove for POD types
> where appropriate, and selecting algorithms based on traits indicating
> if an iterator is a RandomAccessIterator, ForwardIterator, etc.
>

Okay.

> > >    - boost::interprocess support
> >
> > Please elaborate.
>
> Since the pointer type is configurable you can initialize
> static_vector in shared memory with the specialized pointers
> interprocess provides. There is also some example code that uses a
> static_vector with boost::interprocess here: http://goo.gl/oUyj7
>

Interesting. I suppose the pointer type is indirectly specified by the
Strategy?

- Jeff