Question

I have a class:

class A 
{
public:
  virtual void func() {…}
  virtual void func2() {…}
};

And some derived classes from this one, lets say B,C,D… In 95 % of the cases, i want to go through all objects and call func or func2(), so therefore i have them in a vector, like:

std::vector<std::shared_ptr<A> > myVec;
…
for (auto it = myVec.begin(); it != myVec.end(); ++it)
  (*it).func();

However, in the rest 5 % of the cases i want to do something different to the classes depending on their subclass. And I mean totally different, like calling functions that takes other parameters or not calling functions at all for some subclasses. I have thought of some options to solve this, none of which I really like:

• Use dynamic_cast to analyze subclass. Not good, too slow as I make calls very often and on limited hardware

• Use a flag in each subclass, like an enum {IS_SUBCLASS_B, IS_SUBCLASS_C}. Not good as it doesnt feel OO.

• Also put the classes in other vectors, each for their specific task. This doesnt feel really OO either, but maybe I’m wrong here. Like:

  std::vector<std::shared_ptr<B> > vecForDoingSpecificOperation;
  std::vector<std::shared_ptr<C> > vecForDoingAnotherSpecificOperation;
  

So, can someone suggest a style/pattern that achieves what I want?

Answer 1

Someone intelligent (unfortunately I forgot who) once said about OOP in C++: The only reason for switch-ing over types (which is what all your suggestions propose) is fear of virtual functions. (That’s para-paraphrasing.) Add virtual functions to your base class which derived classes can override, and you’re set.
Now, I know there are cases where this is hard or unwieldy. For that we have the visitor pattern.

There’s cases where one is better, and cases where the other is. Usually, the rule of thumb goes like this:

• If you have a rather fixed set of operations, but keep adding types, use virtual functions.
  Operations are hard to add to/remove from a big inheritance hierarchy, but new types are easy to add by simply having them override the appropriate virtual functions.

• If you have a rather fixed set of types, but keep adding operations, use the visitor pattern.
  Adding new types to a large set of visitors is a serious pain in the neck, but adding a new visitor to a fixed set of types is easy.

(If both change, you’re doomed either way.)