On 11 October 2011 20:01, Nathan Ridge <zeratul976@hotmail.com> wrote:
If you are checking all the preconditions yourself, why do you care if it throws or not? [ That sounds glib - but it's a serious question. ]
Why do you care if it ASSERTs, calls abort (), throws, or gets your cat pregnant?
You care because if it throws, it is incurring the runtime cost of checking whether the precondition has been met.
So does the assert. The "complication" is there (performance is a different issue) unless you make it undefined behavior AND ignore it.
The design choice between throwing and undefined behaviour (in release builds, where asserts become no-ops) boils down to the choice of who should check the precondition: the callee, or the caller. Tradition has favoured the caller checking the precondition whenever possible, because the caller has more information and can sometimes check more efficiently (e.g. by eliding the check altogether in cases where it already knows the precondition is met).
And sometimes is less efficient. For instance, if you are populating from StaticVector from list iterators (or any non-random access iterators), it's an O(n) check ahead of time or a complicated wrapper around a one-at-a-time insert. (Note: this is a bug in the current implementation of StaticVector, as its iterator constructor currently requires random access iterators).
Note that vector::push_back() throwing on out-of-memory is *not* a counterexample to this - unlike exceeding the capacity of a StaticVector, running out of memory is not a condition that can be checked beforehand by the caller.
Sure it is. You can duplicate the functionality of exponential growth by calling size(), capacity() and reserve() before doing push_back(). I'd really like to see the interface be as close to C++11 std::vector as possible (other than vector<bool>). -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404