I'll probably attempt to make StaticVector fulfill use case (1) with bounds checking performed using assert, in a way that makes it viable for use internally within AutoBuffer as well if the writer of that library desired to. The way I see things, if I implement StaticVector using assert, someone can inherit from my class and add exceptions if desired. I may be mistaken, but one could not do the same the other way around without any sacrifice, since some implementations of exceptions incur performance penalties.
I don't see the advantage to use internally AutoBuffer here, but maybe I'm missing something evident.
I just saw it as a reasonable place where the code could be reused, for the buffer portion of the autobuffer implementation. Not necessary, just a possibility.
As for check/unchecked bounds, I'll start with push_back being checked, and provide unchecked_push_back + unchecked_insert. I know it is less popular than a policy based implementation but I feel like there will be reduced overhead for compiler implementations with less effective optimizations, though this is based only on others' comments earlier on in the thread. Since this is (for me at least) designed to also be useful for embedded applications which may have stricter requirements, I find this to be a sensible choice.
I will add that the push_back is checked only in debug mode as it will use assert. Then the unchecked version lost its utility on release mode.
perhaps all the checks should only build in debug mode?
I have one additional question regarding the size. It was requested that I use boost::uint_value_t<N>::least, but I am concerned this would inhibit uses where one inherits from StaticVector to add functionality such as what is found in AutoBuffer. Should I stick to std::size_t, boost::uint_value_t<N>::least, or allow the size type to be set with a template parameter?
You can always add a size_type template parameter that is defaulted to
boost::uint_value_t<N>::least.
Best, Vicente
Fair enough, I'll do that. Cheers! Andrew Hundt