Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-09-13 10:11:26

At 10:08 PM 9/12/2001, Thomas Lien wrote:

>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. 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. The way it stands
>now, I never want to use at(int) because eventually
>release versions of my code won't need it anymore. 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. I'm curious is anyone has other opinions about

The existence of at() doesn't preclude an implementation from range
checking operator[](int), either always or based on a preprocessor
symbol. It's a quality-of-implementation issue.

If a preprocessor symbol is used, it must be defined (or not defined) the
same way in all translation units which include the header to avoid a One
Definition Rule violation.

Note too that range checking is not necessarily slower than not range
checking. Some hardware does range checks in parallel. During the
development of the C++ standard, I wrote a test program to see what impact
range checking actually had. The code ran faster with range checking turned
on! Turned out the range checked code happened to align better with
instruction cache lines than the non-range checked code. My memory is a
bit hazy as to what happened when we giggled the code to eliminate the
cache effect, but I think the range checked code was the same speed because
the range check got executed in parallel on another integer execution
unit. Some hardware even has special instructions and registers to do
range checking; I've never tested to see what that does to speed.


Boost list run by bdawes at, gregod at, cpdaniel at, john at