operator==, as a notational convenience. Because operator== just called the IsEqual function, it was all right for it to be inline and not virtual. This does not apply if your function just happens to have a one-line implementation. Another example is constructors or destructors declared empty.
A more subtle question concerns
However, making such an inline declaration precludes supplying a more efficient implementation in the future. Because people often make a test based on the expected outcome, it might be possible to supply custom implementations of == and != that were optimized for expected == and expected !=, respectively. Having an inline implementation of != makes this impossible.
Sometimes having this inline implementation doesn't help, and making the inline declaration saves writing an extra routine (and having extra code). There is a gray line, however, somewhere between the simple case of the same function with two names (like IsEqual and ==) and two substantially different functions. Err on the side of caution; talk to an architect if you are not sure.
Also, if you have a function in an abstract base class, think about whether it should have an empty implementation or be a pure virtual function. If it must be overridden by subclasses, it should be a pure virtual function. If it's acceptable for it not to be overridden, consider whether you really want the empty definition inline. Remember, you might decide to add default behavior to that function some day; if you've made it inline, you no longer have that opportunity.
operator== versus operator!=. Should you define operator!= as an inline that just says !(a==b)? It would be highly questionable to have this be semantically invalid, as that would confuse clients tremendously.
[Contents]
[Previous]
[Next]
Click the icon to mail questions or corrections about this material to Taligent personnel.
Generated with WebMaker