> "It is unneccessary to use G__isinterpretedp2f() API in interpreter > environment because cint will automatically distinguish between the > pointer and handle it properly" Well, the description is maybe not completely clear. If you have an "interpreted" function which takes a pointer as an argument then the cint will automatically manage it. Your problem is that you have a "compiled" function which takes a pointer as an argument - in this case YOU must distinguish between different "kinds" of pointers. That is what the G__isinterpretedp2f is for. > root [2] G__isinterpretedp2f(&pass) > (const int)2 > > so my pointer is a "Pointer to an interface method of user embedded > precompiled global function". What you get here and what you will get in "future" is completely unknown. You MUST be prepared for ANY kind of pointer. > [bernet@daplxa127 posix]$ sh setup > ################################################################ > # makecint : interpreter-compiler for cint (UNIX version) > (...) > then no makefile created... You face the problem that in ROOT the cint's "makecint" malfunctions. The problem is "known" ... for years ... . Please find attached a small example call.cxx which I just prepared. You can use it either as interpreted : root [0] .L call.cxx root [1] call(pass, 2) (int)4 root [2] call(&pass, 4) (int)16 or compiled : root [0] .L call.cxx++ Info in <ACLiC>: creating shared library /..././call_cxx.so root [1] call(pass, 2) (int)4 root [2] call(&pass, 4) (int)16 I do NOT guarantee that everything in this example is correct, but ... as a starting point it should be o.k. Hope it helps, Jacek.
This archive was generated by hypermail 2b29 : Sat Jan 04 2003 - 23:51:23 MET