>I did manage to use makecint to obtain a shared library of my application,
>which involves templated classes. I can also use it in cint, but after a
>".reset", cint crashes when I try use an instantiated template again. Here
>is an example:
>
>[online04] ~/scratch > cint alljets.so
>cint> .x cintmacro.cc
>cint> .reset
>cint> .x cintmacro.cc
>Error: Segmentation violation FILE:cintmacro.cc LINE:13
>Press return or process will be terminated in 10sec by timeout
>
>After a ".reset" I get a crash.
.reset resets everything including alljets.so. So, you try to run cintmacro.cc
without alljets.so after .reset. .reset is, in many cases, confusing. I
recommend using '.U cintmacro.cc' to unload cintmacro.cc only. Or, in fact,
'.x cintmacro.cc' should be doing following sequence inside.
.U cintmacro.cc
.L cintmacro.cc
cintmacro()
>Another question I have is this:
>
>class A {
>private:
> class B { .. }
> HepAList<B>
>}
>
>I have as a data member a templated list with a private nested class as
>the template argument. I could not get this to compile after "makecint"
>unless I made the nested class B public. Is there perhaps a clever use of
>"#pragma link ..." to overcome this?
Following #pragma might do.
#pragma link off class A::B;
#pragma link off HepAList<A::B>;
There is aother one '#pragma link off nestedclass;' but this doesn't help.
I guess HepAList template is in global scope. class A::B may be masked,
but not HepAList<A::B> because this is in the global scope where template
is declared.
This looks like compiler dependent. I tried this on Linux2.0.32 g++ and
found no problem.
>When I use e.g. a member function of my class which takes arguments I get
>a cint crash when I use constants.
>
>The member function "njets" is defined like this:
> int njets( const double & ) const;
>
>In cint I get after successfully creating an object pointed to by bla:
>cint> double yy=0.007;
>cint> int nn=bla->njets(yy);
>This works ok, but when I do it like this it crashes:
>cint> int nn=bla->njets(0.007);
>Error: Segmentation violation FILE:/tmp/aaaaadrra LINE:1
>One needs temporary variables where an explicit constant would do.
This is a known but undocumented limitation. I can implement a workaround
whoch works in case of double and long reference. The problem remains
if you use other fundamental types. I need to think about this.
Difficult part is that you need to have an address for constant somewhere.
>And a few smaller questions:
>o) Can one use the C routine "malloc()" in the cint interpreter? I had
> difficulties...
Yes, you can use malloc() and free() in the interpreter. This is embedded
by default.
(Don't use -q option, if you use malloc/free)
>o) Can one use C++ stream io in the cint interpreter? I found I can only
> do this after doing #include <iostream.h> on the command line.
You need to read iostream.h to use stream I/O. It is technically easy to
read it by default, but I'm not sure if that is right thing to do.
>o) What is the difference between an "automatic" object and an object on
> the free store, allocated with "new"? I observed in the root examples
> that most root objects are created in the free store even in situations
> where an automatic object should also work.
There is no difference. Everything is in the free store. Only the difference
is "automatic" object is automatically destroyed by the interpreter, vs
"new"ed object is not.
class A { .. };
A a1; // "automatic" object, but in the free store
A *p = new A; // "new"ed object
Masaharu Goto