Boost logo

Boost :

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[]
should assert().

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

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

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