This took me ages to figure out, although it's kinduv obvious - you need to include in src/common_cpp/DataStructure/LinkDef.hh

#pragma link C++ class std::vector<MYTYPE>;

where obviously MYTYPE is filled with whatever. If you want to use iterators, you will need to include those as well, I guess something like

#pragma link C++ class std::vector<MYTYPE>::iterator;
#pragma link C++ class std::vector<MYTYPE>::const_iterator;

Note also #1066, which I haven't figured out the solution to yet.

Possibly this is dupe of #1051

1. Add the ' ClassDef() ' macro into your class definition
2. Add the corresponding link line into the LinkDef header from which the ROOT dictionaries are built using rootcint

Cheers
Alex

Yes, for some reason I didn't realise that you need to specify the template type for STL vectors (or it just didn't click quite somehow). But of course template sorting happens at compile time so it's obviously needed in the linkdef... I guess I expect the linker to complain if something is missing from the LinkDef.hh, but for some reason this doesn't happen for STL stuff.

Below is a minimal example implementation:

My Class/structure to be rootable

#ifndef STR_B_H
#define STR_B_H
#include <TObject.h>

struct B {
  ClassDef(B,1)
  int a;
  int b;
};

#endif

and the contents of the LinkDef.h

#ifdef __CINT__

#pragma link C++ class B+;

#endif

• gROOT->ProcessLine(".L struct.h+");

This can also be put into a script called rootlogon.C and will then be called by default when you start root. Note that without this loading of the ROOT dictionary for your rootable objects they will most probably look like leaves and not be understood when you try to access them. You may of course get lucky if your structure is simple but generally they will be unintelligible to root without the dictionary loaded.

Hope that's clear
Cheers
Alex

Can you have a look at the documentation here and here and check that you are happy with it/improve where appropriate? It's in the trunk under doc/doc_src/introduction.tex and doc/doc_src/data_structure.tex respectively

will do.

Also, the processor .hh for the class is:

namespace MAUS {

/** @class SciFiHelicalPRTrackProcessor processor for SciFiHelicalPRTrack */
class SciFiHelicalPRTrackProcessor : public ObjectProcessor<SciFiHelicalPRTrack> {
 public:
    /** Constructor - registers the branch structure */
    SciFiHelicalPRTrackProcessor();

 private:
    IntProcessor _int_proc;
    DoubleProcessor _double_proc;
    ValueArrayProcessor<double> _double_array_proc;
    ValueArrayProcessor<SciFiSpacePoint> _sf_spoint_array_proc;
};
} // ~namespace MAUS

#endif

Alex? Any ideas?

Hi all,

data member '_phi_i' is of type DoubleArray

DoubleArray _phi_i;

Cheers
Alex

I.e. does it fulfil points 1 and 2 above?

In addition you should add the '+' option to the linkdef and also when loading the dictionary as below:

#pragma link C++ class std::vector<double>+;

gROOT->ProcessLine(".L <yourclass>.h+");

This will instruct rootcint to make the streamer functions use readbuffer and writebuffer to handle the streaming.

see http://root.cern.ch/root/roottalk/roottalk01/3751.html where I quote

Unless you have good reasons to implement the Streamer function yourself,
you should always use the option "+" 

Cheers
Alex

Thanks Alex.

DoubleArray was just a typedef for std::vector<double>, as the instructions said that it was neccessary if you were using stl containers with ROOT. Have now removed this and am using std::vector<double> directly. Have also changed the line in LinkDef.hh to

#pragma link C++ class std::vector<double>+;

Have searched for any .h+ files but there don't seem to be any to load. Still seeing the same behaviour in the ROOT output...

Hi Alex,

Thanks for looking at this, and sorry for the slow reply, I was out of the office on Friday. I am in the office today if you are around? My suspicion is that this is not a dictionary issue, but due to the number of nested levels of stl containers we now have in the data structure. Apparently ROOT only supports 3 nested levels, so we may just have passed that limit (1 for level for the spill number, 1 level for the recon event number, 1 level for SciFiHelicalTracks). See http://root.cern.ch/root/roottalk/roottalk05/2690.html for a discussion. Be a pain if that is the case, but not sure what we can do about it.

Ad

Hi Adam,
This nested problem looks like it related to the drawing of the data structure or scanning. It should not stop you from storing said structure or retrieving it using the streamers. Have you checked that you can store a sample event and recall it using the streamers. I will be around tomorrow, will you be around then?
Cheers
Alex

I'm afraid that I have not got as firm a grasp of the MAUS data structure as yourselves. I assume the nesting levels here that your talking about amounts to there being multiple recon events per spill and multiple SciFiHelicalTracks per recon event right?

--Alex

Yes, that's pretty much it, but the fact that we store multiple spills also counts I think.
Ad

Well assuming that a spill is synonymous with an event then you could remove one layer there as root is already geared up for storing events. i.e. you wouldn't need a separate spill object, you could just attach the branches for the recon events etc directly. You would still be able to iterate over the structure at the event/spill level using fill/readEvent.

--Alex

Alex I sat down and looked at this earlier. It does seem to be the inherent ROOT limitation in viewing beyond three nested levels. The data is safely stored, but is not available via Scan or Draw. If converting from the ROOT file to JSON the data reappears, confirming this. It should also be possible to access the data by loading it back in to classes.

Chris, could you comment on Alex's last point above, about simplifying the implementation of the data structure in ROOT, so we have 1 less nested loop? After that I think we can close this.

Ack ROOT is a mess. No, we stick with the structure as defined, I don't want to mess with that. It took too much effort setting it up and, well, the spill is the correct thing to have at the root level.

Can you do something like

spill -> vector1 -> vector2
            \         ||       
             \        \/
              \---> vector3

where vector2 holds a pointer to vector3?

Storing the data and retrieving it again isn't the problem, so I assume that you could do this. Whether ROOT would be any better at letting you Draw/Scan this is anyone's guess, one would have to try.

I should point out that while an inconvienience it isn't the end of the world as the data is still stored and retrievable so you can still make the plots by looping over the data yourself. In fact TTree has a makeClass method which creates the code for you to do just this. Including adding any cuts or whatever you need. Back in the day we used to do a lot of our analysis in ATLAS using the makeclass classes.

Cheers
Alex