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

Subject: Re: [boost] [container] static_vector: fixed capacity vector update
From: Andrew Hundt (athundt_at_[hidden])
Date: 2013-01-23 16:36:35

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

It supports Boost.Move.

> > 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).

We could put everything into detail and only have one variant as the
public interface. However demand was so high for different behaviors
in different situations during the original discussion that we made it
strategy/policy defined. Even if it isn't part of the public
interface, it might be reasonable to leave them in for those that want
to mess with some of the internals a bit for their use case.

> > >   - 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;

Now that I think about it I believe when exceptions are disabled
BOOST_THROW_EXCEPTION calls a function that is supposed to deal with
whatever went wrong if possible, and that may be the most appropriate
behavior in that case.

> 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).

I haven't seen at() used but unfortunately it should still work.

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

Yes, the strategy defines the pointer type similarly to how an allocator does.

Cheers!
Andrew Hundt