-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Marshall Clow Sent: 10 October 2011 23:36 To: boost@lists.boost.org Subject: Re: [boost] Interest in StaticVector - fixed capacity vector
On Oct 10, 2011, at 3:47 AM, Peter Myerscough-Jackopson wrote:
Andrew Hundt <athundt <at> gmail.com> writes:
On Sun, Aug 14, 2011 at 5:55 AM, Andrew Hundt <athundt <at>
gmail.com> wrote:
<snip>
three.push_back(2); // size: 2 capacity: 3 three.push_back(3);
three.push_back(1); // throws std::out_of_range exception indicating the capacity has been exceeded
Is there any chance that the error behaviour code be configurable. StaticVector looks ideal for embedded environments, BUT commonly exceptions are disabled in such an environment. It would be nice to have asserts instead of exceptions available in all cases, so that a programmer can check for room on a push_back prior to calling it. A specific StaticVector macro would suffice for those that need it.
IMHO, That's the whole point of using BOOST_THROW_EXCEPTION(x) instead of a naked "throw x"
If exceptions are disabled, then BOOST_THROW_EXCEPTION just calls exit().
BOOST_THROW_EXCEPTION can be set to call a user defined function boost_throw_exception, I am unaware of BOOST_THROW_EXCEPTION calling exit(). The real issue is that even setting BOOST_NO_EXCEPTION and BOOST_EXCEPTION_DISABLE, the user of a library is still required to defined the boost_throw_exception function EVEN if the user checks that calls are valid, i.e. the user performs their own capacitycheck and rangecheck prior to calling. This means that you cannot compile up a library including StaticVector without exceptions without defining boost_throw_exception, even though because you check conditions prior to calling functions. This pollutes the library unnecessarily, and means users of a library that uses StaticVector have to provide a function that is not used (boost_throw_exception) or that if they have defined it for their own needs then it is somewhat concerning that an imported library may appear to want to call it. Both of these are bad, and the same issue exists inside boost::function. To resolve this it would be useful to have an extension to the interface in some form to allow a pushing and popping action to occur without a range/capacity check function that can throw, but I would like to propose that an assert is called instead. To maintain safety the checking functions could return success/failure, and the calling functions maintain the object's state invariants based upon the return code. Alternatively the push/pop functions could also return bool signifying success/failure. In looking at this I also note that there is a StaticVector( Iter begin, Iter end ) that calls capacitycheck(). This then potentially throws, is this truly desirable in a constructor? I see in a number of places where the StaticVector is essentially copying from another unknown storage class that could be larger than the StatcVector that it also could throw, did you consider merely copying all that could be copied? i.e. the first N objects are copied. I can't think if that would be better or worse? It would certainly circumvent the need for checking/throwing in some places. Yours, Peter Ps. As an aside the capacity check function could be static.