Header file already loaded

Hi rooters

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.

Cristian

Hi,

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=“Axel”]Hi,

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

Hi,
I’d say check the doc for TROOT::Reset()…
Axel.

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”.