The C programming language—which C++ is nearly backward-compatible with—was originally developed for writing operating systems. As such, it had to enable the programmer to write as close to the metal as possible, producing code nearly as efficient as assembly or machine code.In the old days of computing, it was interesting, even exciting, to see how use of pointers could speed up your programs. In the 1980s, I honed my C-language programming skills by writing several different versions of Conway’s Game of Life. In the first version, I processed two-dimensional arrays the obvious way, with array indexes. For example, to zero-out an array:int i = 0;int j = 0;for (i = 0; i < NROWS; i++) { for (j = 0; j < NCOLS; j++) { grid[i][j] = 0; }}(Note: this being ancient C code, I couldn’t declare i or j inside the loops.)Here was the version using a pointer to do the same thing but far more efficiently:int **p = grid;int **end = grid + NROWS + NCOLS;for (p = grid; p < end; p++) { **p = 0;}By using this optimization, along with a few other tricks, I sped up the Game of Life by a factor of ten! At first the gliders, pulsars, floaters, and other “organisms” were moving like snails; but after my optimizations, they were zipping across the screen at blinding speed. The gliders were moving so fast I could hardly see them! I had to start adding in delay mechanisms to control the speed.You should be able to see why—especially with 2D arrays—array processing was so much faster with pointers. Rather than laboriously calculating each cell positions by using indexes, the pointer version zipped through the array by incrementing one integer position after each iteration until reaching “end,” an address that was calculated just once, ahead of time.Incidentally, a decent optimizing compiler would have done that calculation for me, but I took the task upon myself. I should’ve been able to write:int **p = grid;for (p = grid; p < grid + NROWS + NCOLS; p++) { **p = 0;}The problem with this use of pointers for efficiently processing arrays is that it has become largely superfluous. In accordance with Moore’s Law, processors have become thousands of times faster than in the 1980s. Memory is far more plentiful and much cheaper, so that allocation of an extra variable here or there should hardly concern you anymore.The bottom line is that unless you’re writing part of an operating system or device driver with a piece of code designed to be executed millions of times a second, you are hardly ever going to feel the difference between arrays processed with indexes versus arrays processed with pointers.And that is why the newer generation of languages—Java, C#, and VB.NET—don’t support pointers at all. The philosophy behind these languages is that any code-optimization you would get from using a pointer to process an array is a trivial matter given today’s hardware. Instead, you use array indexes, and those indexes are automatically checked to see if they are in bounds.Safety first is the philosophy of these languages.All these language also support a for each statement (also called “ranged-based for”), which the C++11 specification now supports as well. The beauty of this feature is that it keeps array references strictly under the control of the compiler, not permitting i to go out of bound, but it also permits the compiler to internally optimize array-access technique for greatest efficiency. With C++11, here’s how I’d zero-out my array:for (int &i : grid) { i = 0;}This version doesn’t use pointers. But note that it uses—yo
