C++: Magic callbacks solved

Post by Nico Brailovsky @ 2009-08-03 | Permalink | Leave a comment

Long post this time - and lots of code too. How fun iz that? Anyway, remember where we left last time? We're supposed to make this work:

class Callee {
 Callback notify;
 public:
  Callee(Callback notify) : notify(notify) {}
  void finish(){ notify(this); }
};
class Caller {
  Callee c;
  public:
  Caller() : c(Callback(this, &Caller::im_done)) {}
  void im_done(Callee*) { }
};

I'll write about the different solutions I've tried and the problem each of these solutions had:

Experiment 1: Templates

We could to this the easy way, with a template:

template <class Callback>
class Callee {
  ...
};
class Caller {
 template <class T>
 void operator() (T p){ this->im_done(p); }
  ...
};

This has some drawbacks: 1. We need to change the definition of the Callee 2. The Caller can only have one callback (or overloaded one callback) 3. It's boring

Experiment 2: Template virtual method

So, lets try another approach: the naive one is an interface:

class iCallback {
  public:
  template <class T> void operator () (T o) = 0;
};

Looks great, doesn't it? Too bad it's not valid C++, you can't have a virtual template method (what would the vtable size be?). If we can't have a template method let's make a template class:

template <class T>
class iCallback {
  public:
  virtual void operator () (T o) = 0;
};
class Callee {
 iCallback<Callee> notify;
  public:
  Callee(iCallback<Callee> notify) : notify(notify) {}
 void finish(){ (notify)(this); }
};
class Caller : public iCallback<Callee> {
 Callee c;
  public:
  Caller() : c(this) {}
  void im_done(Callee) {}
 void operator ()(Callee o){ im_done(o); }
};

It may not be pretty but it works. Also, adding a callback means adding a new operator (). Lets try to improve it a little by removing the nasty inheritance (remember, always prefer composition over inheritance):

Experiment 3: Callback Object

template <class P>
class iCallback {
 public:
  void operator () (P o) = 0;
};
template <class T, class P>
class Callback : public iCallback<P> {
 // Notice this typedef: we have an object of type T and a
  // function accepting a parameter P
  typedef void (T::member_func) (P);
  T cb_obj; member_func f;
 public:
  Callback(T cb_obj, member_func f)
     : cb_obj(cb_obj), f(f) {}
 inline void operator() (P o){
    (cb_obj->f)(o); // ->* is the best voodoo operator
  }
};

This new object should help us to: 1. Implement different callback functions (not tied to an operator() nor a type overload) while staying type-safe 2. Delete the inheritance 3. Use the arrow-asterisk operator (!) which is way cool

How would this change leave our code?

class Caller;
class Callee {
 Callback<Caller, Callee> notify;
 public:
  Callee(Callback<Caller, Callee> notify) : notify(notify) {}
  void finish(){ (notify)(this); }
};
class Caller {
 Callback<Caller, Callee> cb;
  Callee c;
  public:
  Caller() : cb(this, &Caller::im_done), c(&cb){}
  void im_done(Callee*) {}
};

Oops, looks like we took one step back: now Callee MUST know the type of Caller. Not nice. Luckily it is an easy fix:

Experiment 4: Callback interface

class Callee {
  iCallback<Callee> notify;
  public:
  Callee(iCallback<Callee> notify) : notify(notify) {}
 void finish(){ (*notify)(this); }
};

OK, we're back on track. We will solve that weird looking (*notify)(this) later, don't worry.

We're almost there, but specifying the callback as is ugly, Caller should be automagically inferred from the context by some template voodoo. Let's do it by implementing a wrapper:

template <class R>
class WraperCallback {
  iCallback<R> cb;
  public:
    template <class T, class F>
    WraperCallback(T cb_obj, F f)
       : cb( new Callback<T, R>(cb_obj, f) ) {}
    ~WraperCallback() {
      delete cb;
   }
   inline void operator()(R o){
     (*cb)(o);
    }
};

Now we no longer need to specify the Caller type. There's still a nasty issue about pointer-vs-object passing. Using (*notify)(this) is very ugly so let's do it like this:

Experiment 5: Callback object bis

class Callee {
  WraperCallback<Callee> notify;
  public:
  Callee(WraperCallback<Callee> notify) : notify(notify) {}
 void finish(){ notify(this); }
};
class Caller {
  Callee c;
  public:
  Caller() : c(WraperCallback<Callee>(this, &Caller::im_done)) {}
 void do_it(){ c.finish(); }
  void im_done(Callee) { }
};

Nice, this time it should work as expected. Only it does not, there is something horribly wrong about it. Can you see what it is? Take a second, I'll wait... OK, back? Right, it segfaults! Why? Easy, take a look at this:

  Callee(Callback<Callee*> notify) : notify(notify) {}

We are using a copy constructor here, and what does our wrapper store?

    WraperCallback(T* cb_obj, F f)
       : cb( new Callback<T, R>(cb_obj, f) ) {}

Indeed, the copied WrapperCallback ends up pointing to a deleted Callback when the cb field of the original object gets copied and then destructed. We should have all the pieces to fix it now: we just need to implement the copy operator to make it work. How does the final version looks like?

Solution

template <class P> class iCallback {
  public:
    virtual void operator()(P) = 0;
    virtual iCallback<P> clone() const = 0;
};
template <class T, class P>
class RealCallback : public iCallback<P> {
  typedef void (T::member_func) (P);
  T cb_obj; member_func f;
 public:
  RealCallback(T cb_obj, member_func f)
     : cb_obj(cb_obj), f(f) {}
 /
   * The clone operator is needed for the copy ctr of
   * the Callback object
  /
  inline iCallback<P> clone() const {
   return new RealCallback<T, P>(cb_obj, f);
  }
 inline void operator() (P o){
    (cb_obj->f)(o); // -> is the best vodoo operator
 }
};
template <class R>
class Callback {
  iCallback<R> cb;
  public:
    template <class T, class F>
    Callback(T cb_obj, F f)
       : cb( new RealCallback<T, R>(cb_obj, f) ) {}
    Callback(const Callback& cpy)
        : cb( cpy.cb->clone()) {}
    ~Callback() {
      delete cb;
   }
   inline void operator()(R o){
     (*cb)(o);
    }
};

Conclusion

Now we have a nice callback object which can link two objects without them knowing each other. There is room for future improvement, of course: 1. Got any ideas to implement a generic callback to a function with an unknown number of params? I don't (variadic templates == cheating!) 2. I'm quite sure the param type for the callback could be inferred in some magical template way, but I don't know how. 3. Think of anything else to add? Let me know in the comments!

In reply to this post, Nicolás Brailovsky » Blog Archive » Template metaprogramming XI: Hidden Agenda commented @ 2010-07-20T14:10:19.000+02:00:

[...] for every table; something like this: See the problem? To do something like that we’d need a virtual template method, and you can’t have that. After seeing that I thought to myself “Hey, I’ll use [...]

Original published here.

In reply to this post, Nicolás Brailovsky » Blog Archive » Newsflash: C++ object commits sepuku commented @ 2011-04-04T09:30:53.000+02:00:

[...] you launch a background job, and you don’t really care when it’s done. You may use a callback to be notified when the job is done, but if you don’t really care then having an object which [...]

Original published here.