Transition from ROOT5 to ROOT6

ROOT6 is similar to ROOT5

• It comes with the same library of classes (base classes, histogram classes like TH1, ...) which share the same interface as under ROOT5
• It provides a command line interface as ROOT5, and runs macros just like under ROOT5

There are however some differences between ROOT5 and ROOT6, which will be discussed in this section.

aliBuild -z --defaults root6 build AliPhysics

CLING: ROOT's just-in-time compiler

For the command line interface and running macros ROOT5 uses CINT, which is an interpreter for C/C++.

• An interpreter processes a macro line-by-line
• It depends on the implementation of the interpreter how C++ code will be handled and how close the interpretation comes to the language standard

Macros can however also be run in the compiled mode by ROOT5 (adding a "+" to the macro name). In this case

• ROOT calls an external compiler to compile the macro to a library which is loaded into ROOT
• Once the macro runs in compiled mode it is expected to be fully compatible with the C++ standard and coding error free as the compiler will not tolerate compiler errors.

CLING

In contrast to this ROOT6 uses a just-in-time compiler called CLING. A just-in-time compiler

• translates each statement, no matter whether it is a single command or a complicated macro, into machine code as it would be a program and
• only afterwards runs this piece of code.

In order to translate code into machine code the compiler must know how to translate every single line. Based on powerful compiler library this means for ROOT6 that all macro must comply to 100% with the C++ language standard, and exceptions will not be tolerated. Furthermore this also means that all symbols and objects must be known at compile time. This has three side effects:

• Loading Functions with gROOT->LoadMacro(...);: This function loads all functions it finds within the macro into ROOT during run time.
  • For an interpreter this is sufficient as the functions are used after they are loaded.
  • However the compiler must know all symbols used in a macro at compile time.
• Loading libraries with gSystem->Load(...);:
  • Here we have the same problem!
  • The symbols in the libraries must be known before they are used.
• Compiling (ALICE analysis) tasks on the fly with gROOT->LoadMacro("...+");:
  • As the analysis task compiled like this will be converted in a library it must be know to the just-in-time compiler before.

For all three cases exist workarounds which will be discussed in the next sections. -In general macros which were running under ROOT5 in the compiled mode will also run under ROOT6.

• Macros which were running only in the interpreted mode might contain coding errors which were not handled by ROOT5 and might therefore need fixes.
• However the just-in-time compiler will give precise error messages leading exactly to the lines which need fixes.

How can I call macros inside macros?

Calling macros inside macros is a bit tricky as the result of a macro will be available only at runtime. There are however several workarounds which cover the most common use cases:

• Using ROOT's TMacro:

  TMacro is a wrapper class around the macro processing. It is constructed with the macro path. The macro is run using TMacro::Exec. The result of TMacro::Exec() is a number representing an address in memory where to find the resulting object. This has to be cast into a pointer to an object of the expected type. Example:

TMacro physseladd(gSystem->ExpandPathName("$ALICE_PHYSICS/OADB/macros/AddTaskPhysicsSelection.C"));
AliPhysicsSelectionTask *physseltask = reinterpret_cast<AliPhysicsSelectionTask *>(physseladd.Exec());

The macro is still evaluated at runtime, however with the reinterpret_cast to AliPhysicsSelectionTask * we tell ROOT that the result of the macro interpretation must be of type AliPhysicsSelectionTask *, so the type is known at compile time.

TMacro::Exec optionally gets a string representation of the function arguments. This might be a bit complicated to handle, particularly if the arguments are dynamic and change at run time. The method works both for ROOT5 and ROOT6.

• Using gROOT/gInterpreter->ProcessLine:

  Macro execution can be launched as well via gROOT->ProcessLine() / gInterpreter->ProcessLine().

  • As with TMacro this method is focused on running a macro and not loading content from it.
  • The ProcessLine method returns a long number representing an address in memory where to find the output objects.
  • This number has to be cast to the expected output type using a reinterpret_cast in order to access the content of the output objects.

The following example runs the add macro for the physics selection task:

  AliPhysicsSelectionTask *physseltask = reinterpret_cast<AliPhysicsSelectionTask *>(gInterpreter->ProcessLine(Form(".x %s", gSystem->ExpandPathName("$ALICE_PHYSICS/OADB/macros/AddTaskPhysicsSelection.C"))))

Adding function arguments is possible here as well as a simple string representation after the macro path, surrounded with (). This method also works both under ROOT5 and ROOT6.

• Including macros:

  As ROOT6 compiles the macro it is possible to include macros and treat them as if they were header files. In order for this to work it is essential to tell ROOT before where to find the macro. This can be done using the preprocessor macro R_ADD_INCLUDE_PATH(...). For the just-in-time compiler macros included will look as if they were part of the code itself. The following macro runs under ROOT6:

  #ifdef __CLING__
  // Tell  ROOT where to find AliRoot headers
  R__ADD_INCLUDE_PATH($ALICE_ROOT)
  #include <ANALYSIS/macros/train/AddESDHandler.C>

  // Tell ROOT where to find AliPhysics headers
  R__ADD_INCLUDE_PATH($ALICE_PHYSICS)
  #include <OADB/macros/AddTaskPhysicsSelection.C>
  #endif

  void simpleaddtest(){
    AliAnalysisManager *mgr = new AliAnalysisManager;

    // Take function from macro AddESDHandler
    // no gROOT->LoadMacro for ROOT6
    AddESDHandler();

    AliPhysicsSelectionTask *test = AddTaskPhysicsSelection(kTRUE);

    mgr->InitAnalysis();
    mgr->PrintStatus();
  }

In particular when passing arguments to the macro (in the example above passing kTRUE to AddTaskPhysicsSelection) this method is very convenient. This method is specific to ROOT6. The part including macros has to be protected (see below).

// C++ program to demonstrate working of raw string. 
#include <iostream> 
using namespace std; 

int main() 
{ 
    // A Normal string 
    string string1 = "Geeks.\nFor.\nGeeks.\n" ;  

    // A Raw string 
    string string2 = R"(Geeks.\nFor.\nGeeks.\n)";  

    cout << string1 << endl; 

    cout << string2 << endl; 

    return 0; 
} 

Geeks.
For.
Geeks.

Geeks.\nFor.\nGeeks.\n

    TString arguments = R"((kTRUE, "test.root"))";
    AliAnalysisTaskDummy *task = reinterpret_cast<AliAnalysisTaskDummy*>(gInterpreter->ProcessLine(".x AddTaskDummy.C" +  arguments));

What about loading libraries that are not automatically loaded?

ROOT can load libraries automatically via so-called rootmaps, but if you compile your own class, on which you are developing, in a steering macro, this class is not known to ROOT and therefore cannot be auto loaded. This can be cumbersome. However, you can load your compiled classes within a macro by hand.

In a ROOT session, do

    .L myDummyClass.cpp++g

This will generate a shared object file (.so). Now, in a given macro in which you want to access your class, write in the preamble

    R__LOAD_LIBRARY(myDummyClass.so)

which will load the shared library, and give you access to all the symbols defined within. Note the syntax: despite what you might expect, the word myDummyClass should not be put within quotes ""!

Do I need to include header files in my macros?

ROOT6 comes with a technique called pre-compiled header files. Header files from a certain library are compiled to a binary format by rootcling, the successor of rootcint, and loaded into ROOT6 by an auto-loading mechanism similar to the rootmap mechanism.

Once rootcling is invoked with the argument -rml name a .pcm-file is created containing the pre-compiled headers. ROOT6 will search for .pcm-files in the LD_LIBRARY_PATH.

For libraries providing .pcm-support NO headers should be included in macros.

For libraries handled by the user make sure to

• run rootcling with the arguments -rmf for the .rootmap file and -rml for the .pcm file
• Install both the .rootmap and the .pcm file of your library path in the library location (usually PROJECT_PATH/lib)

Once you have done this, there is no need anymore to e.g. call R_LOAD_LIBRARY(myDummyClass.so) when you want to access symbols defined in myDummyClass; rather than that, the corresponding library will be automatically loaded by ROOT once a symbol defined in it is encountered.

Troubleshooting: I get a huge amount of errors, and my macro doesn't run. What can I do?

Here are few examples that commonly appear in user macros and which are tolerated by ROOT5 but not anymore by ROOT6:

• Undefined symbols:

  Maybe you have something like this in your code:

  taskname = "mytask";
  

  The variable taskname was not defined before. It was implicitly defined in ROOT5 as const char *. In ROOT6 this leads to the error

  error: use of undeclared identifier 'taskname'
  

  The variable taskname must be defined with a type before a value can be assigned. In this case the proper code would be

  const char *taskname = "mytask";
  

  Thanks to C++11 ROOT6 can also detect the type implicitly using the keyword auto. In this case the code looks the following:

  auto taskname = "mytask";
  

  This will however not be transparent to ROOT5 as ROOT5 doesn't understand C++11.

  Note: On the command line ROOT6 automatically adds the auto keyword. The statement above will be possible in the interpreted mode of ROOT6.

• Missing forward declarations

  Consider this macro:

  void fail_forward() {
    int result = test(2,4);
    printf("2 + 4 = %d\n", result);
  }
  
  int test(int a, int b) {
    return a + b;
  }
  

  Under ROOT5 this macro will run, but under ROOT6 it will raise the following compiler error:

  error: use of undeclared identifier 'test'
  

  The function test is defined, but after it is used. In ROOT5 this is no problem: During interpretation the interpreter loads all functions. But under ROOT6 the macro is compiled, and now the order matters: Functions need to be declared before they are used. Adding a forward declaration is sufficient in order to make the macro working. The following version of the macro will run also under ROOT6:

  int test(int a, int b);
  
  void run_forward() {
    int result = test(2,4);
    printf("2 + 4 = %d\n", result);
  }
  
  int test(int a, int b) {
    return a + b;
  }
  

• Handling of pointer and objects:

  ROOT5 does not enforce using the proper access operator for objects, pointers and references, but will allow the usage of the operator -> for references and the operator . for pointers. ROOT6 distinguishes between them, and consequently the proper access operator needs to be used.

  Consider the following macro:

  void fail_access(){
    TH1F *ptr = new TH1F("ptr", "ptr", 1, 0., 1.);
    ptr.SetTitle("test1");
    printf("Title 1: %s\n", ptr.GetTitle());
  
    TH1F obj("obj", "obj", 1, 0., 1.);
    obj->SetTitle("test2");
    printf("Title 2: %s\n", obj.GetTitle());
  }
  

  Consequently the wrong access operator is used. ROOT5 will warn about the incorrect access operator, but it will run the macro. Trying this under ROOT6 ends in the following errors:

  ...: error: member reference type 'TH1F *' is a pointer; did you mean to use '->'?
  ptr.SetTitle("test1");
    ~~~^
       ->
  ...: error: member reference type 'TH1F *' is a pointer; did you mean to use '->'?
    printf("Title 1: %s\n", ptr.GetTitle());
                            ~~~^
                               ->
  ...: error: member reference type 'TH1F' is not a pointer; did you mean to use '.'?
    obj->SetTitle("test2");
    ~~~^~
       .
  ...: error: member reference type 'TH1F' is not a pointer; did you mean to use '.'?
    printf("Title 2: %s\n", obj->GetTitle());
                            ~~~^~
                               .
  

How do I distinguish between ROOT5 and ROOT6 in my macros?

Sometimes macros require different treatment for ROOT5 and ROOT6. It is then necessary to know which ROOT version is used while the macro is running.

ROOT5 defines the preprocessor macro __CINT__, which can be used to check whether one is in an interpreter session. In current (up to at least v6-12-04) however also ROOT6 exports __CINT__, so this macro cannot be used to distinguish between ROOT versions.

ROOT6 in addition __CLING__ which is not present in ROOT5. The following lines indicate how to run ROOT5/ROOT6 specific code:

#if defined(__CLING__)
  // ROOT6-specific code here ...
#elif defined(__CINT__)
  // ROOT5-specific code here ...
#endif

I heard TF1 has changed fundamentally. Is there something to be aware of?

TF1 is based on TFormula for the formula representation. TFormula got a heavy change:

• In ROOT5 formulas were always interpreted on-the-fly.
• With ROOT6 they are compiled by the just-in-time compiler.

While this leads to a significant speedup in particular when the formula is evaluated multiple times (in fit procedures for example) it comes on cost of breaking backward compatibility, for which reading TFormula/TF1 object created with ROOT6 with ROOT5 will lead to errors.

For what concerns TFormala a ROOT5-compatible version has been added to ROOT6 as ROOT::v5::TFormula, however something similar does not exist for TF1. In order to read a TF1 object from a ROOT file under ROOT5 it has to be created under ROOT5.

Now my macro finally works under ROOT6. Will it still work under ROOT5?

It depends whether the macro now contains something which ROOT5 does NOT understand.

• ROOT6 is fully compatible with C++11. In ROOT5 C++11 support is not implemented, but the standard C++98 is used. C++11-specific code will not be understood.
• All NEW features provided by ROOT6 are of course not ported to ROOT5. This in particular affects:
  • TTreeReader
  • TProcPool
  • TDataFrame
  • ...
• Standard library support in ROOT5, while it comes out-if-the-box in ROOT6. If the macro should run under both ROOT versions consider ROOT containers instead.
  • If your classes write stl-containers containing ROOT-objects to a ROOT-file they must be declared to ROOT5 in your LinkDef.h file. Example:

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

    For ROOT6 this is not necessary.

Exercise

The exercise here is to find some old macros you have, that worked under ROOT5 - and see how 'C++ compliant' they actually are, but loading them in a ROOT6 session.