templates and builtin functions
Richard B. Kreckel
kreckel at thep.physik.uni-mainz.de
Fri Nov 2 15:25:13 CET 2001
Dear Masaharu,
On Fri, 2 Nov 2001, Masaharu Goto wrote:
> 1. Do you really need to compile above template function?
> 2. Or can you accept that this one being interpreted?
>
> In case of 1. , it is unfortunate I see no solution. In case of 2.
> I think it is as simple as to load template source file at run time.
>
> Or do I still miss something? If so, I will review your message again.
> I spent only a few minutes reading it...
No, you are not missing something. I probably was. Having this
interpreted rather than precompiled is obviously the Right Thing (tm).
Thanks for your clarifying comments. Now, given a header file containing
only the definition
template<typename T1>
inline const GiNaC::function cosh(const T1 &p1) {
return GiNaC::function(GiNaC::function_index_cosh, GiNaC::ex(p1));
}
in the GiNaC-Cint interface I can write:
Welcome to ginaccint V1.0.1 (GiNaC V0.9.9, Cint V5.15.10)
__, _______ GiNaC: (C) 1999-2001 Johannes Gutenberg University Mainz,
(__) * | Germany. Cint C/C++ interpreter: (C) 1995-2001 Masaharu
._) i N a C | Goto and Agilent Technologies, Japan. This is free software
<-------------' with ABSOLUTELY NO WARRANTY. For details, type `.warranty'
Type `.help' for help.
>> #include "testheader_cintfunction.h"
>> //ginaccint.function
next expression can be a function definition
>> ex EulerNumber(unsigned n)
> {
> const symbol xi;
> const ex generator = pow(cosh(xi),-1);
> return generator.diff(xi,n).subs(xi==0);
> }
creating file /tmp/ginacbt5aGZ
>> cout << EulerNumber(60) << endl;
18108911496579230496545807741652158688733487349236314106008095454231325
>> quit;
removing file /tmp/ginacbt5aGZ
I am almost happy. There are just the following problems left:
1) I cannot just #include <ginac/function.h> and <ginac/inifcns.h>, where
such things are declared. This is because Cint doesn't really seem
to be #including them. Probably because it has already done so while
ginaccint was compiled and the include guards of these header files are
still active. I think I can work around this problem by simply
#undef'ing the include guards and reloading those two headers in some
automatic way. First attempts look promising...
2) ...but resolution of the proper function is still not correct in Cint!
Consider cosh as above, but now sitting in namespace GiNaC:
>> cout << GiNaC::cosh(1) << endl; // this is clear
cosh(1)
>> cout << cosh(1) << endl; // one could say this should be ambigous
1.54308
>> using GiNaC::cosh;
>> cout << cosh(1) << endl; // now it should be clear, but it really called...
1.54308
>> cout << std::cosh(1) << endl; // ...this one. :-(
1.54308
Could using declarations like the above one be properly supported by
Cint?!?
As an aside, why does G__cpp_whatever.h #include <math.h>? Is this really
needed? (I seem to be able to just delete it prior to comiling
G__cpp_whatever.cpp).
Regards
-richy.
--
Richard Kreckel
<Richard.Kreckel at Uni-Mainz.DE>
<http://wwwthep.physik.uni-mainz.de/~kreckel/>
More information about the GiNaC-devel
mailing list