From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-13 08:34:43
From: "Thomas Lien" <tgunlien_at_[hidden]>
> I want to comment about how index checking is handled
> in the std::vector and vicariously in boost::array. I
> feel having two different methods, operator(int) and
> at(int), to specify whether you want to have index
> checking is bad design.
Perhaps. However, conceptually, this is not specifying whether you want
index checking or not. Usage of the appropriate method specifies the
_response_ to the situation where an invalid index is being passed.
operator has undefined behavior, while at() has a well defined behavior.
> A better way would be to
> decide at compile time whether or not you want to
> index check, possibly based on preprocessor values
> NDEBUG or perhaps INDEX_CHECKING.
Which is exactly what I'd expect from a quality implementation. operator
> The way it stands
> now, I never want to use at(int) because eventually
> release versions of my code won't need it anymore.
If you don't expect to use invalid indices, you shouldn't have a need for
at(), and this is by design.
> understand that the since the standard does this,
> boost::array wanted to mimic it. IMHO, however, I
> believe index checking is best decided at compile
It's not about compile vs run time (runtime decision would imply a
checking_on() / checking_off() member functions) but about granularity. Do
you want index checking controlled at
* whole program level (global macro);
* class level (policy);
* instance level (constructor parameter);
* point of usage level (operator vs at).
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk