Elias,
> Actually you are right, but CINT seems to resolve correct the ctor, since
> I added a call to G__CallFunc::GetPrototype() before calling the ctor and
Well, I'm not sure that that is a sufficient check. My guess of a wrong
overload being selected is based on looking at the TF1 source. The error
message that you got is not emitted by the proper overload.
> At first, when I was thinking of a way to support this, I was puzzled and
> one thought was to use CINT to create C functions at run-time; I think this
> is, more or less, what you do in PyROOT.
Sortof. The main idea is to be able to associate state (in my case the
callable python object, be it a function or class instance with __call__
defined) with a raw C pointer.
> Finally, I picked up a more elegant solution, IMHO, which does not use
> CINT. I just maintain a table with ROOT function names and Ruby methods,
> and I call the appropriate one using TF1::GetCurrent().
It is more elegant, but doesn't work with in a multi-threaded environment,
which you always have when you plot functions in canvases. That's why I
dismissed it right away when looking for a solution.
> But, in order to support this feature in my way, I need CINT to be able
> to set correctly a function pointer to the argument list of G__CallFunc
> instance; something that I can't figure out how is done.
This is exactly what my code solves, without required changes in CINT. But
yes, it is very ugly. Also, my code works well if the data members of the
associated python callabale instance chanages. That won't work with a raw
function pointer.
Best regards,
Wim
--
Wim.Lavrijsen@cern.ch -- WLavrijsen@lbl.gov -- www.lavrijsen.net
"Stop making excuses for your software." --first step towards quality
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:09 MET