I have a simple file where I laod a header file. In this header file I declared a bunch of names like #define NFILES 20;
Now I load this header file in my root script with the statement #include <myheader.h>
I can run the script fine the first time after I begin the root session. However, if I run it for the second time or more in the same root session, it says:
Note: File “myheader.h” already loaded
Error: Symbol NFILES is not defined in current scope myscript.C:40:
I can go around this problem by restartitng the root session everytime I need to run the script. There must be a more practical and obvious way to go around this problem, right? Please, I thank you in advanced for any comments about this.
Note: I start my script file with the command gROOT->Reset(); but it seems this is not enough to download the myheader file from the system.
don’t use gROOT->Reset(). Could you post an example of two files (header + source) that shows this behavior, as short as possible but still such that I can run it and see the error message?
don’t use gROOT->Reset(). Could you post an example of two files (header + source) that shows this behavior, as short as possible but still such that I can run it and see the error message?
Axel.[/quote]
Hello Axel
Yes, I removed the line gROOT->reset() and now I can run the file “.x peakfit.C” as many times as I want. Do you know what does that line do?
Thank you again,
Kris
Ok, as a quick reference… I notice that gROOT->Reset() actually resets all global variable and functions. It may case, since I am loading a header file, this function does not download the header files, but it does erase all the variables declared in that header file.
Kris
void TROOT::Reset(Option_t *option)
{
// Delete all global interpreter objects created since the last call to Reset
//
// If option=“a” is set reset to startup context (i.e. unload also
// all loaded files, classes, structs, typedefs, etc.).
//
// This function is typically used at the beginning (or end) of a macro
// to clean the environment.
if (IsExecutingMacro()) return; //True when TMacro::Exec runs
if (fInterpreter) {
if (!strncmp(option, “a”, 1)) {
fInterpreter->Reset();
fInterpreter->SaveContext();
} else
gInterpreter->ResetGlobals();
if (fGlobals) fGlobals->Delete();
if (fGlobalFunctions) fGlobalFunctions->Delete();
SaveContext();
Remark:
gROOT->Reset()
removes all the objects in the stack but does not reset objects in the heap. So for example:
//Quad: class that allows to solve quadratic equations
root[] .L Quad.cxx
root[] Quad my_object(1.,2.,-3.);
root[] Quad *my_objptr = new Quad(4.,5.,-6.);
root[] gROOT->Reset();
You will see that this deletes the first object but not the second. We have also painted ourselves into a corner, as my_objptr was also on the stack. This command will fail:
root[] my_objptr->Solve();
CINT no longer knows what my_objptr is. This is a great example of a memory leak; the heap object exists but we have lost our way to access it. In general, this is not a problem. If any object will outlive the compound statement in which it was created then a more permanent pointer will point to it, which frequently is part of another heap object. See Resetting the Interpreter Environment in the chapter “CINT the C++ Interpreter”.