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