Is there any way to avoid declaring virtual methods when storing (children) pointers?

Question

I have run into an annoying problem lately, and I am not satisfied with my own workaround: I have a program that maintains a vector of pointers to a base class, and I am storing there all kind of children object-pointers. Now, each child class has methods of their own, and the main program may or not may call these methods, depending on the type of object (note though that they all heavily use common methods of the base class, so this justify inheritance).

I have found useful to have an "object identifier" to check the class type (and then either call the method or not), which is already not very beautiful, but this is not the main inconvenience. The main inconvenience is that, if I want to actually be able to call a derived class method using the base class pointer (or even just store the pointer in the pointer array), then one need to declare the derived methods as virtual in the base class.

Make sense from the C++ coding point of view.. but this is not practical in my case (from the development point of view), because I am planning to create many different children classes in different files, perhaps made by different people, and I don't want to tweak/maintain the base class each time, to add virtual methods!

How to do this? Essentially, what I am asking (I guess) is how to implement something like Objective-C NSArrays - if you send a message to an object that does not implement the method, well, nothing happens.

regards

Answer 1

You can do what you describe in C++, but not using functions. It is, by the way, kind of horrible but I suppose there might be cases in which it's a legitimate approach.

First way of doing this:

Define a function with a signature something like boost::variant parseMessage(std::string, std::vector<boost::variant>); and perhaps a string of convenience functions with common signatures on the base class and include a message lookup table on the base class which takes functors. In each class constructor add its messages to the message table and the parseMessage function then parcels off each message to the right function on the class.

It's ugly and slow but it should work.

Second way of doing this:

Define the virtual functions further down the hierarchy so if you want to add int foo(bar*); you first add a class that defines it as virtual and then ensure every class that wants to define int foo(bar*); inherit from it. You can then use dynamic_cast to ensure that the pointer you are looking at inherits from this class before trying to call int foo(bar*);. Possible these interface adding classes could be pure virtual so they can be mixed in to various points using multiple inheritance, but that may have its own problems.

This is less flexible than the first way and requires the classes that implement a function to be linked to each other. Oh, and it's still ugly.

But mostly I suggest you try and write C++ code like C++ code not Objective-C code.

Answer 2

This can be solved by adding some sort of introspection capabilities and meta object system. This talk Metadata and reflection in C++ — Jeff Tucker demonstrates how to do this using c++'s template meta programming.

If you don't want to go to the trouble of implementing one yourself, then it would be easier to use an existing one such as Qt's meta object system. Note that this solution does not work with multiple inheritance due to limitations in the meta object compiler: QObject Multiple Inheritance.

With that installed, you can query for the presence of methods and call them. This is quite tedious to do by hand, so the easiest way to call such a methods is using the signal and slot mechanism.

There is also GObject which is quite simmilar and there are others.

Answer 3

Instead of this:

// variant A: declare everything in the base class
void DoStuff_A(Base* b) {
  if (b->TypeId() == DERIVED_1) 
      b->DoDerived1Stuff();
  else if if (b->TypeId() == DERIVED_2) 
      b->DoDerived12Stuff();
}

or this:

// variant B: declare nothing in the base class
void DoStuff_B(Base* b) {
  if (b->TypeId() == DERIVED_1) 
      (dynamic_cast<Derived1*>(b))->DoDerived1Stuff();
  else if if (b->TypeId() == DERIVED_2) 
      (dynamic_cast<Derived2*>(b))->DoDerived12Stuff();
}

do this:

// variant C: declare the right thing in the base class
b->DoStuff();

Note there's a single virtual function in the base per stuff that has to be done.

If you find yourself in a situation where you are more comfortable with variants A or B then with variant C, stop and rethink your design. You are coupling components too tightly and in the end it will backfire.

I am planning to create many different children classes in different files, perhaps made by different people, and I don't want to tweak/maintain the base class each time, to add virtual methods!

You are OK with tweaking DoStuff each time a derived class is added, but tweaking Base is a no-no. May I ask why?

If your design does not fit in either A, B or C pattern, show what you have, for clairvoyance is a rare feat these days.

Answer 4

If you are planning to create many different children classes in different files, perhaps made by different people, and also I would guess you don't want to change your main code for every child class. Then I think what you need to do in your base class is to define several (not to many) virtual functions (with empty implementation) BUT those functions should be used to mark a time in the logic where they are called like "AfterInseart" or "BeforeSorting", Etc.
Usually there are not to many places in the logic you wish a derived classes to perform there own logic.