Re: [boost] Index Checking

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

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.

--Beman