Re: [boost] Interest in StaticVector - fixed capacity vector

Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2011-10-12 13:21:09

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

An assert does not incur a runtime cost in release builds. It's just a tool
to help catch programming mistakes in debug builds. From an interface
perspective, it's just as if the function assumes the precondition is met
and invokes undefined behaviour otherwise.

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

Fine, "condition that can be checked beforehand by the caller" is not a
sufficiently precise criterion for what should throw and what should assert.

A more precise criterion is to assert when failing to meet a precondition is
a programming/logic error, and throw when it's something beyond the
programmer's control. (Hacks aside, that usually corresponds to conditions
that can be checked beforehand by the caller, and ones that cannot, but this
more precise criterion captures the essence better.)

My point is, exceeding a capacity bound known at compile time clearly falls 
into the former category, while running out of memory falls into the latter.

Regards,
Nate