Difference in StreamerInfo

Dear ROOTers,

I can’t solve the following problem.
I created two classes EventHeader and RawData(see in att.), which look more or less identical. However StreamerInfo looks quite different, which causes a warning, when loading a tree. The difference is in the treatment of my personal type
uint32 and uint8. In the EventHeader uint32 data members are treated as unsigned int, while in the RawData they are BEC::uint32. I failed to produce a short example.
Do you have any hints, for my numerous attempts to figure out the difference and hence the reason for the warning failed?
My comp. OS is SLC3.
[ul]


  •                                     *
    
  •    W E L C O M E  to  R O O T       *
    
  •                                     *
    
  • Version 5.12/00 10 July 2006 *
  •                                     *
    
  • You are welcome to visit our Web site *
  •      [root.cern.ch](http://root.cern.ch)            *
    
  •                                     *
    

FreeType Engine v2.1.9 used to render TrueType fonts.
Compiled on 11 July 2006 for linux with thread support.

CINT/ROOT C/C++ Interpreter version 5.16.13, June 8, 2006
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0] gSystem->Load(“libbc.so”); using namespace BEC;
root [1] gROOT->GetClass(“RawData”)->GetStreamerInfo()->ls();

StreamerInfo for class: BEC::RawData, version=1
BEC::uint32 fBchr1 offset= 4 type=13 signal in Cherenkov 1
BEC::uint32 fBchr2 offset= 8 type=13 2
BEC::uint32 fBchr3 offset= 12 type=13 3
BEC::uint32 fS10 offset= 16 type=13 signal in scint.counter 10
BEC::uint32 fS11 offset= 20 type=13 11
BEC::uint8 fBtype offset= 24 type=11 beam type
BEC::uint8 fNguar offset= 25 type=11 number of target guard counters
int fGuard[6] offset= 28 type=23 signal in a counter
i= 0, fBchr1 type= 13, offset= 4, len=1, method=0
i= 1, fBchr2 type= 13, offset= 8, len=1, method=0
i= 2, fBchr3 type= 13, offset= 12, len=1, method=0
i= 3, fS10 type= 13, offset= 16, len=1, method=0
i= 4, fS11 type= 13, offset= 20, len=1, method=0
i= 5, fBtype type= 11, offset= 24, len=1, method=0
i= 6, fNguar type= 11, offset= 25, len=1, method=0
i= 7, fGuard type= 23, offset= 28, len=6, method=0
root [2] gROOT->GetClass(“EventHeader”)->GetStreamerInfo()->ls();

StreamerInfo for class: BEC::EventHeader, version=1
unsigned int fNumber offset= 4 type=13 number
unsigned int fSpill offset= 8 type=13 spill
unsigned int fTapeId offset= 12 type=13 tape id
unsigned int fTape offset= 16 type=13 tape number
unsigned char fBeamType offset= 20 type=11 type of beam
unsigned char fNvtx offset= 21 type=11 vertices
unsigned char fNtrkInPV offset= 22 type=11 tracks in the Prim.Vertex
unsigned char fNcls offset= 23 type=11 clusters
unsigned char fNphotonCls offset= 24 type=11 photon clusters
unsigned char fNpi0 offset= 25 type=11 neutral pions
unsigned char fNeth2g offset= 26 type=11 ethas decaying to 2 photons
unsigned char fNsiPhotons offset= 27 type=11 single(unpaired) photons
i= 0, fNumber type= 13, offset= 4, len=1, method=0
i= 1, fSpill type= 13, offset= 8, len=1, method=0
i= 2, fTapeId type= 13, offset= 12, len=1, method=0
i= 3, fTape type= 13, offset= 16, len=1, method=0
i= 4, fBeamType type= 11, offset= 20, len=1, method=0
i= 5, fNvtx type= 11, offset= 21, len=1, method=0
i= 6, fNtrkInPV type= 11, offset= 22, len=1, method=0
i= 7, fNcls type= 11, offset= 23, len=1, method=0
i= 8, fNphotonCls type= 11, offset= 24, len=1, method=0
i= 9, fNpi0 type= 11, offset= 25, len=1, method=0
i=10, fNeth2g type= 11, offset= 26, len=1, method=0
i=11, fNsiPhotons type= 11, offset= 27, len=1, method=0
root [3] TFile ftree(“tree.root”); TTree tree = (TTree)ftree->Get(“tree”);
Warning in :
The StreamerInfo for version 1 of class BEC::EventHeader read from file tree.root
has a different checksum than the previously loaded StreamerInfo.
Reading objects of type BEC::EventHeader from the file tree.root
(and potentially other files) might not work correctly.
Most likely you the version number of the class was not properly
updated [See ClassDef(BEC::EventHeader,1)].
[/ul]
BecConfig.h (136 Bytes)
EventHeader.h (2.49 KB)
RawData.h (1.32 KB)

[quote]I created two classes EventHeader and RawData(see in att.), which look more or less identical. However StreamerInfo looks quite different, which causes a warning, when loading a tree. The difference is in the treatment of my personal type [/quote]Why do you think that the error message is due to a difference between those 2 unrelated classes?

Usually this warning message appear when there is a difference between the library you use to write the file and the library you use to read it (for the same class). Most likely you changed the data member definition between the two (possibly changed from #define to typedef).

Cheers,
Philippe.

Because i’m sure that it’s one and the same library.
BTW if i will change the type, say, to “int” everything will be ok.
Well, i’d like to slightly change the formulation. Why the StreamerInfo displays
uint32 data members as “unsigned int” in one case and as “BEC::uint32” in the other. although in both cases they are really BEC::uint32?

Regards, Valery.

If i will I put explicitly unsigned int instead of uint32 in the EventHeader the warning will disappear.

[quote] Why the StreamerInfo displays uint32 data members as “unsigned int” in one case and as “BEC::uint32” in the other. although in both cases they are really BEC::uint32? [/quote]I don’t see any obvious reasons why this would be the case. Could you send a complete example reproducing the problem?

Cheers,
Philippe

At last, i have marked the following tricky case.
Objects of the EventHeader and RawData classes are contained in a Container, which
also doesn’t inherit from TObject. The way of treatment BEC::uint32 type data members depends upon the order of “include” directives of this classes headers
in the Container header file with respect to some other ‘#include"MyClass.h’.
BTW MyClass inherits from TObject.
I’ll try to prepair something.

Hi,

The problem is due to an annoying bad interaction between the way the dictionary initialize themselves and the ROOT autoloader.
Depending on when the autoloader is called some of the class might be incorrectly step.

Namely in your case, the class Track depends on TVector2.
In consequence libPhysics.so is loaded as soon as the Track class is processed.
The consequence is that any classes set-up before Track will be wrong; any classes setup after Track will be correct.
Hence the sensivity to the include order you have seen.

You have a very simple work-around :slight_smile:. Simply load libPhyscis before loading your library:

root [0] gSystem->Load("libPhysics.so"); root [1] gSystem->Load("libbc.so"); using namespace BEC; root [2] gROOT->GetClass("RawData")->GetStreamerInfo()->ls();

We plan on correcting this behavior when we introduced the new version of CINT (which will produce new dictionaries).

Cheers,
Philippe.