The Horror of Compile-Time Binding

11 Apr 2006

I’m working on this C++ project, and suddenly realize how much we’re using the visitor pattern. The point of the visitor pattern is to extract non-core functionality out of data-bearing classes, instead gathering that functionality into a visitor class that knows how to operate on all the data-bearing classes. You do this by making each “visitable” class implement a method that accepts a visitor object, which in turn calls a method in the visitor to do its work, along these lines:

void MyClass::accept(Visitor &v)
{
    v.visitMyClass(this);
}

That way, new visitors can be created to implement new functionality involving visitable classes, without the visitable classes needing to be changed or even recompiled. Here’s where the fun kicks in. For each new “visitable” class I add, I need to add a member function for each existing visitor, which means editing dozens of .h and .cpp files, adding a small “visitXXX” member function to each.

The kicker is that most of the functionality we’re implementing with visitors consists of either trivial one-liners or empty implementations for most of the visitable types. So we have visitor classes containing dozens of identical member functions. Nothing quite like the joy of editing dozens of files to insert meaningless boilerplate code!

At first I wondered what my co-workers were thinking when they set out on this path, but eventually I came to realize, much to my chagrin, that this is an inescapable reality of C++ programming in many situtations, thanks to the compile-time binding that C++ does. The compile-time binding actually precludes you from doing certain things without this sort of indirection.

To see why this is, first consider an example that demonstrates how things can work in a more full-featured OO language, such as python. Consider the following python program:

class A:
    def emit(self):
        print "Class A"

class B (A):

    def emit(self):

        print “Class B”
a = A()

b = B()

a.emit()

b.emit()

print “-—”

objects = [a, b]

objects0.emit()

objects1.emit()

This code snippet defines and manipulates a simple class hierarchy, with B inheriting from A. Common sense tells you what the output of this program may be:

Class A

Class B

-—

Class A

Class B

And your common sense would be right. Whe calling the emit method on the a and b objects, the correct method is triggered and the corresponding class names are output.

Now then, considering the following C++ program:

#include <iostream>
class A
{
public:
    virtual void emit() {
        std::cout << "Class A\n";
    }
};
class B : public A
{
public:
    virtual void emit() {
        std::cout << "Class B\n";
    }
};
int main (int argc, char * const argv[]) {
    A a;
    B b;
    a.emit();
    b.emit();
    std::cout << "-----\n";
    A objects[] = {a, b};
    objects[0].emit();
    objects[1].emit();

return 0;
}

Does your common sense tell you this program should have the same output as the earlier python version? Think again:

Class A

Class B

-—

Class A

Class A

Say what? “But, but, but, I put an instance of B in that array, wtf?” Well, here’s where C++’s compile-time binding came and shot you in the foot. Note that C++ doesn’t offer any sort of generic array of objects. Whether using a C array as I’ve done, or a std::vector object, you must indicate the type of the object, in this case the root of our hierarchy, A. C++ then makes use of this type information when your program is compiled to match up the call to emit with the implementation in the named class, rather than the implementation in the derived class you’re actually instantiating! Doh!

This has dire consequences for any situation where you’ve got a collection of objects of varying types. Say you’ve got a bunch of model classes, and you’d like each class to emit an xml string containing its values. In Objective-C, Python, Ruby, Smalltalk, and probably even Perl and Javascript, this is pretty straightforward; You just give each class a method that emits a string (and, assuming you’ve got an acyclic directed graph, calls the emitting method in each of its “child” objects). Then you just call the emitting method in the root object, and away you go. For example, once again consider some python:

class RootElement:
    def emitXml(self):
        print "<root>"
        for child in self.children:
            child.emitXml()
        print "</root>"
class SomethingElement:
    def emitXml(self):
        print '<something value="', self.value, '"/>'
class SomeoneElement:
    def emitXml(self):
        print '<someone value="', self.value, '"/>'

r = RootElement()

c1 = SomethingElement()

c2 = SomeoneElement()

c1.value = “first child”

c2.value = “second child”

r.children = [c1, c2]

r.emitXml()

(Note that this code breaks encapsulation quite a bit in setting attributes on the objects, and is not what I’d do in production code. But python lets you do it, and it makes examples short and sweet, so there you have it.)

Now then, that code outputs about what you might expect:

<root>
<something value=" first child "/>
<someone value=" second child "/>

Simple, right? Well, if you try to do something similar in C++ (or Java for that matter), you’ll run into trouble. You can start by giving your element classes a common parent declaring emitXml (don’t need to bother with such a thing in python, where method calls aren’t bound to implementations until runtime), but as soon as you have something like RootElement maintaining a list of child elements, you’ll hit the same snag in our earlier example; the relevant implementations of emitXml will be passed over in favor of the generic implementation in the parent class.

Which is where the visitor pattern comes in. It’s basically a kludge to work around the compile-time binding limitation of C++. Even when there are times you’d want to use it in order to extract responsibilities out of a data-bearing class, you still end up with this ridiculous double-dispatch syntax (compare with Objective-C, where you can actually add methods to an existing class by using a category, so you can accomplish the same design feat of grouping functionally-related methods together, yet outside the classes they operate on, without the artifices of the visitor pattern).

The moral of this story is that the visitor pattern is a necessary evil for statically-bound languages like C++. And that if you want to avoid this evil thing, start by avoiding C++. Really, pick up python or ruby or Objective-C or whatever. Really!

[update] fixed some typos, thanks weinholt

Tweet

Comments