Calling interpreted methods from compiled code

I am trying to call methods of a interpreted class from compiled code.
The idea is to have a callback mechanism where the callback handlers
can be interpreted code, loaded on the fly.
Ideally I want something like:

// This should be compiled into a shared object .so /.dll file
class Callback : public TObject
virtual void Handle(MyDataType& data) = 0;

class Process : public TObject
Run(Callback* handler)
MyDataType data;
// do some work …
// more work …

// This should be in some cxx file to be loaded and interpreted on the fly.
class MyHandler : public Callback
virtual void Handle(MyDataType& data)
cout << “got data” << endl;
// do something with this data …

When I naively tried to do the above for a small example I ran into seg faults
very quickly. Replacing the “= 0” in the abstract Callback class with "{}"
fixed the seg fault but the child class MyHandler’s methods were never called.
I found a message on the forum archives explaining that the problem is with
a different mechanism of achieving polymorphism in CINT compared to a compiler.
The message also contained an example of generating stub code in the dictionary
to overcome this problem. The example was for the makecint utility.
However I am having real problems generating the stub code for a realistic example
using rootcint. How does one generate stub code using rootcint?
Will the stubbed classes also be properly inheritable in interpreted code using

I also tried looking at the TMethodCall class. But this does not seem to work
when I try to call interpreted class methods using TMethodCall.
Is there a way or is this impossible?

I also found a rather long message: … /0407.html
which shows how to call interpreted or compiled methods from compiled code.
However it uses low level CINT API method calls. From this it seems to me that
TMethodCall should also work since internally it also must use the API calls.

What is the difference between using API calls, TMethodCall and generating stub
code? What is the right choice of approach for what I want to do?


Hi Artur,

this functionality is already implemented via the very flexible signal/slot mechanism (which of course internally is doing the necessary MethodCalls etc.). For more see

Cheers, Fons.