Campuses:
This is an old revision of the document!
The ROOT team says that the main features of ROOT are:
This is completely unhelpful and totally misleading. Only somewhat more to the point, they describe the mission of ROOT thusly:
The ROOT system provides a set of OO frameworks with all the functionality needed to handle and analyse large amounts of data in a very efficient way. Having the data defined as a set of objects, specialised storage methods are used to get direct access to the separate attributes of the selected objects, without having to touch the bulk of the data. Included are histograming methods in 1, 2 and 3 dimensions, curve fitting, function evaluation, minimisation, graphics and visualization classes to allow the easy setup of an analysis system that can query and process the data interactively or in batch mode.
This description is still singularly unhelpful for the novice trying to make sense of how to accomplish his or her first task. A more useful description would be to say that, depending on the user, ROOT is:
The ROOT team goes on to say:
It also provides a good environment to learn C++.
In fact, ROOT is a terrible environment to learn C++. ROOT was designed before the Standard Template Libraries, which provide the bulk of the familiar C++ functionality, were implemented. It therefore has separate, totally incompatible implementations of things like vectors and strings. Code written using ROOT does not translate easily to the 99.999% of C++ world that does not use ROOT.
ROOT also makes heavy use of “interpreted C++” (using Cint, the C++ Interpreter), a concept which essentially does not exist outside of ROOT. It encourages sloppiness with pointers and other woes.
ROOT is written without the use of namespaces, a C++ concept that helps organize code. This is why all ROOT classes start with “T”, as in TTree, TFile, etc. The correct (or perhaps “modern”) way to do this would be to make a ROOT namespace so that the objects are called ROOT::Tree and ROOT::File. Or with “using namespace ROOT;” at the top of your code, they would be simply Tree and File.
The ROOT code shows evidence of having been developed without a good understanding of object-oriented ideas. The most commonly cited example is the wonky use of inheritance. The notion of one class inheriting from another is supposed to mean that the inheriting object has the relationship “is a kind of” with its parent. For instance, an object that represents squares should inherit from one that represents quadrilaterals, which should inherit from one that represents polygons. However, the root class TH2, a 2-dimensional histogram, inherits from a TH1, a 1-dimensional histogram. Most people would agree that a 1-dimensional histogram is a kind of 2-dimensional histogram; it's one where the second dimension is 1 bin wide. The ROOT inheritance is exactly backwards here.
ROOT's internal objects often do not correspond well to the user's idea of what an object should be. For instance, suppose there's a window on the screen that contains several histograms. In ROOT-speak, the window is called a “canvas” or a “pad” (all fine and good). Since, in the user's mind, the canvas has several attributes (size, background color), the histogram has several more (number of bins, bin contents) and the axis yet more (range, number of tick marks), it's clear that to modify the behaviour of the axis, one would do something to the axis object. Yet in fact, to switch an axis between logarithmic and linear, the user must call a function on the canvas.
The Standard Template Library, which defines the usual versions of strings, vectors, lists, maps, and so on, is documented at sgi.com and in many books and other webpages. Always use these instead of the incompatible versions that ROOT provides (i.e. TString, TVector) unless you are forced not to by pre-existing code.
If you follow this, your code will be easier to port to a different system if you decide to move away from ROOT. You will also be able to communicate better with people outside of the ROOT world and you will have better programming skills for when you are outside of the ROOT world.
ROOT's documentation encourages use of objects when writing procedural code would be easier and more clear. For instance, they push you to load your data into an object which has functions defined on it that print and loop over the data (abbreviated from this Fermilab page):
class MyClass {
public :
TTree *fTree; //pointer to the analyzed TTree
//Declaration of leaves types
Event *event;
//List of branches
TBranch *b_event;
MyClass(TTree *tree=0);
~MyClass() {;}
Int_t GetEntry(Int_t entry);
void Init(TTree *tree);
void Loop();
void Show(Int_t entry = -1);
};
This is insanity. Instead, simply prepare your TTree object (probably loaded from a file) and write ordinary functions that operate on it:
void Loop(TTree * awesomedata)
{
for(int i = 0; i < awesomedata->GetEntries(); i++){
awesomedata->GetEntry(i);
// brilliant analysis code goes here
}
}
void analysis()
{
TFile * datafile = new TFile("newdata.root");
TTree * awesomedata = (TTree *)datafile->Get("fish");
Loop(awesomedata);
}
Root encourages or uses the following names:
These names are extremely problematic. “MyClass” is bad because it is totally undescriptive. Use a name that actually represents what data your class holds. (It also may give the impression that the names of classes have to start with “My”. This is not the case.) The other, very short, names are bad both because they are undescriptive and because it is nearly impossible to search for them in files.
C++ has, in practical terms, no limit on the length of variable or function names. While it's not good to use extremely long names either, it's perfectly fine to name your histogram “december_data_hist”. If you totally can't think of a good name for the new variable you just made, run:
/local/minos/bin/variablename
It outputs two short nouns stuck together. It won't be very descriptive, but at least it will be searchable.