for storing and accessing a sequence of objects in memory, you cannot have a construct more efficient (in terms of both time and space) than an array. it is, however, also a very low level data structure with two fundamental properties:
a. an array doesn't know its own size.
b. the name of an array decays to a pointer to its first element very easily.
these have many consequences:
1. any checking has to be provided by the programmer. a good programmer is acutely aware of this and usually gets the size right, but it's extra work and someone can make a mistake.
2. there can be no array assignment
3. arrays with automatic/static storage durations are of a fixed size determined at compile time. (and arrays with a dynamic storage duration decay into pointers before you can access them. C99 allows variable array bounds for local arrays, but VLAs do not come without their own problems.)
4. array decay into pointers interact very badly (incorrectly) with inheritance. for example
struct base { void foo() ; /* ... */ };
struct derived : base { /* ... */ };
void bar( base array[], size_t sz )
{ for( size_t i=0 ; i<sz ; ++i ) array[i].foo() ; }
int main()
{
derived d[20] ;
bar( d, 20 ) ; // disaster
}
in almost all cases there are better (easier to write, easier to read, less error prone, and almost as fast) alternatives. for example
std::vector<> provides a fast unchecked array subscript operator, and the member function
at with checked element access. many implementations (most notably microsoft) also provide bounds-checked iterators (and if they do not, it is easy enough to write one of your own). in general, try to avoid using arrays in c++.
several approaches to the problem of bounds checking have been attempted. these include
a. static checking
i. modify c in a fashion that makes such errors easier to detect.
ii. look only at the source code
b. fat pointer systems
replace every pointer value with a structure that describes the valid range for the pointer, and replace every pointer read/write with code that checks this structure.
c. pointer guards
variation on the theme of fat pointers. Rather than keep the extended data in the pointer itself, a new object is generated which can be located given the location of the pointer it is associated with. This object stores the meta-data associated with the pointer.
d. fence posts
an approach to bounds checking based on placing regions at the end of every allocated block, and trapping any access to those regions. commonly implemented in hardware.
e. object tracking
accomplished by noting when every object is constructed and building a data structure that can identify the object located in a given memory address. when pointer access/arithmetic occurs, the original object is looked up.
these are some popular bounds-checking implementations
ccured http://manju.cs.berkeley.edu/ccured/
cyclone http://www.research.att.com/viewProject.cfm?prjID=67
splint http://www.splint.org/
tinycc http://fabrice.bellard.free.fr/tcc/
valgrind http://valgrind.org/info/
rational purify http://www-306.ibm.com/software/awdtools/purify/
electric fence http://directory.fsf.org/project/ElectricFence/
parasoft insure++ http://www.parasoft.com/jsp/products...product=Insure
more information:
http://www.doc.ic.ac.uk/teaching/pro...ewSuffield.pdf 
Unsolved 
