Strange behaviour of TTree

Dear ROOTers
I want to read event tree structure. I decided to use UniGen format but there is something that I can’t understand. When I run my code like this:

void run3(){ gROOT->ProcessLine(".L UParticle.cpp+"); gROOT->ProcessLine(".L URun.cpp+"); gROOT->ProcessLine(".L UEvent.cpp+"); UEvent *uevent = new UEvent();; TCanvas *c1 = new TCanvas(); TH1D *m = new TH1D("fNpa","fNpa",100,0,1000); TFile *file= new TFile("../event_1.root"); TTree *fChain = (TTree*)file->Get("events"); fChain->SetBranchAddress("event",&uevent); Long64_t entries = fChain->GetEntries(); for(i=0;i<10;i++){ fChain->GetEntry(i); int j = uevent->GetNpa(); m->Fill(j); std::cout<<i<<" "<<j<<std::endl; } m->Draw(); }
I get proper distribution of event multiplicities in my file but when change :

gROOT->ProcessLine(".L UParticle.cpp+"); gROOT->ProcessLine(".L URun.cpp+"); gROOT->ProcessLine(".L UEvent.cpp+");
to

gROOT->ProcessLine(".L UParticle.cpp"); gROOT->ProcessLine(".L URun.cpp"); gROOT->ProcessLine(".L UEvent.cpp");
instead of get multiplicities I got only zeros. What is reason of such behaviour?

Hi,

I am not sure what the reason for this behavior could be, but why would you want to load the compiled sources instead of just loading the shared library. Assuming this comes from libPluto I would

gSystem->Load("libPhysics"); // dep of libPluto which still isn't loaded automatically
gSystem->Load("libPluto");   // or use the full path to libPluto

instead of your calls to gROOT::ProcessLine.

It’s strange but I can’t load libPluto.so I receive error:

Btw. I don’t use pure ROOT installation but ROOT as part of FairROOT framework

Hi,

that symbol comes from ROOT’s libHist. I know that from

$ grep ZN3TF16BrowseEP8TBrowser $ROOTSYS/lib/*

Try loading it also. And maybe file a bug report with your developers so that they finally do record their libraries’ link-dependencies correctly and user are not bothered with manually loading this stuff.

Ok I think I know why I can’t load this library I need some others to be loaded first and what is worse I have to rebuild project because I have upgraded ROOT version #-o

I loaded

gSystem->Load("libEG");
gSystem->Load("libPhysics");
gSystem->Load("libPluto");

and there is still the same situation: when I add + or ++ this works well otherwise gives zero

Hi,

again, why do you load the sources? libPluto comes with a ROOT dictionary so you can use any functions and classes in it by just loading the library. Or are you now talking about other files now?

Do you understand what these “+” and “++” mean?

In short … as “honk” says … if your loaded “libPluto” library provides dictionaries for your “UParticle”, “UEvent” and “URun” classes, you should NOT create them again (i.e. no need to “.L SomeClass.cxx+[+]”).
If there is no library that provides dictionaries for your classes, you MUST create them “on the flight” using ACLiC (i.e. with “.L SomeClass.cxx+” or “.L SomeClass.cxx++” -> the usual reason for the ACLiC requirement is … one meets one or more CINT limitations).

I know what means this “++” signs. When I remove UParticle and UEvent I get error “undefined reference” so I think that those classes are not in libPluto :confused: . They are external classes. But I don’t understand behave of CINT: when I call .L Class.cpp this code (and all methods for Class) are loaded into CINT, aren’t they? when I add “+” then CINT don’t load macro but build and load library. I other words when I build shared object or create executable file (with Makefile dictionary and other stuff) everything work but when I try to do the same with class that has beed red by CINT I get different behaviour.
Maybe for CINT is impossible to read classes that has been “interpreted”.

TROOT::LoadMacro
TROOT::Macro
TSystem::CompileMacro
CINT limitations (concepts, ISO compatibility)
CINT limitations (sizes, lengths)

OK. I understood CINT limitations 8) .