[Xorp-hackers] xorp callback code replacement?

Ben Greear greearb at candelatech.com
Tue Sep 20 09:28:25 PDT 2011


On 09/20/2011 07:02 AM, Steven Simpson wrote:
> Hi Ben,
>
> On 20/09/11 01:10, Ben Greear wrote:
>> * callback code is generated by a python script, and results in
>>      templated c++ code that I simply cannot understand.
>>      This also makes it very hard to add debugging code as well (say,
>>      a string name; object so we can identify callbacks generically,
>>      or similar.)
>
> Without native variadic templates (C++0X?), I doubt you can get away
> from that.  However, I notice a little redundancy in
> libxorp/callback_nodebug.hh (starting at line 275):

I was thinking we'd have a generic Callback object, maybe
something like:

class Callback {
   Callback(CallbackArgs* a);

   /* rv can be NULL if you do not care about return code */
   virtual void process(CallbackReturn* rv) = 0;

   bool hasReferenceTo(CallbackRef* obj);

  private:
   CallbackArgs a;
};

class CallbackArgs {
   CallbackArgs(CallbackRef* r);

   virtual bool hasReferenceTo(CallbackRef* obj);

  private:
   CallbackRef* r;
};

class CallbackRef {
   const string& getName() const { return name; }

  private:
   string name;
};

class CallbackReturn {
   virtual void getMessageString(string* rv) { };
   virtual int getReturnValue() { return 0; } // maybe return an enum instead?
};


Code that actually uses callbacks would spend a lot of time
implementing CallbackArgs and Callback child classes to do their
specific work and hold the pertinent callback-args data.

Anything that passes itself in as an object to be accessed by the
callback would inherit from CallbackRef.  This is primarily to
allow easy debugging hooks so when we crash we can at least figure
out what callback caused it.

Instead of using raw pointers for callback ref, it could be a ref-counted
object, but in my opinion, being lazy about memory use often just creates other
problems (for instance, if the object is logically deleted from the system,
and we reference it in a callback, that could cause all sorts of un-expected
behaviour, even if the memory in question is perfectly valid as far as
new/delete is concerned.)

Thanks,
Ben


-- 
Ben Greear <greearb at candelatech.com>
Candela Technologies Inc  http://www.candelatech.com



More information about the Xorp-hackers mailing list