With a small tweak to Herb's idea, you can use it as an optimization tool sometimes. If you don't like my example classes, please ignore them, and mentally insert your own substitute.

Consider the following set of classes. A base class Array, and two subclasses, LinearArray, SegmentedArray. The LinearArray ensures that the array is always a single fixed block of RAM, usable by memcpy, fwrite, fread, and with quick access. The SegmentedArray tries to avoid realloc type calls by allocating memory in pages. The pages might not be sequential in memory, and thus is useless to memcpy, etc. There are times when each array type is appropriate.

Now, imagine you want a base class such that you can have code that doesn't really care how the array works, it just needs an array. The first instinct is to make a base class with 'operator[]' virtual... and it works fine. The trouble is, if you *know* you have a LinearArray, you're taking quite a bit of extra overhead to use the virtual function to fetch from the array instead of a simple inlined 'return m_pMem[nIndex]'.

So, instead, in the base class lets make the operator[] non-virtual, and call a virtual GetElement(idx).

The derived class implements GetElement(idx), and a newer non-virtual operator[] which doesn't use GetElement(). In fact, the GetElement of the derived class can probably use the operator[] of the derived class, so you don't duplicate code.

What does this gain us? If you use the base array class, it uses the necessary virtual method to access the array. If you know you're using the derived version you get quicker access a nicely inlined non-virtual call. Thus, operator[] uses the most optimal code path based on what it knows of the data type.

Now, VS.NET 7.1 Whole program Optimization might already do this, since at link time it can tell a method isn't derived further. If you're using another compiler (or don't think WPO does this) and you do a lot of unneccessary virtual calls, this could be a useful trick.