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