ROOT should be rewritten from scratch

Hi All!

I entered into ROOT world not much time ago. With some expirience in software development.

And. My eyes bleeding when I look at ROOT. Everybody say that ROOT is C++ framework. Unfortunately, it is not. ROOT at best is writtent in “C with classes”. Written by Fortran-brain-damaged people with pathological love to global variables (gPad, gROOT etc.).

Here is some random whinnings for ya:

Global object ownership to make C++ memory management easier (“Let’s choose language with manual memory management and heroically fight with it!”)…

Homegrown C interpreter, RTTI (“Let’s choose static typed compilable language and make it look like scripting one, without performance loss” (fail))…

Interpreter can’t into templates? No problem, let’s inherit the whole Universe from TObject and put casts everywhere. But now we can put histogram, kitten and airplane in one container!

Ofc, I understand. It was a long time ago. There haven’t been boost, Qt and C++14. Nobody was CS major. Poor scientists just tired of fortran and wished more comfortable instrument. Does ROOT need beautiful desing so much? Don’t think so. Data analysis done by mostly linear code with some loops and branches. Will class hierarchies help much? I doubt.

But I believe that something could be done better.

I’ve finished. Please don’t hit hard.


Won’t hit hard, on the contrary: I agree with much of what you’ve said! :slight_smile:

  • This is why we have released ROOT 6. It replaces the “home grown interpreter” CINT by an interpreter that uses the JIT engine (and everything else) from clang + llvm.
  • And this is why we are redesigning large parts of ROOT for ROOT 7, see … ribution/3

Let us know if there’s something we overlooked! In general I’d recommend you to browse through the presentations of the ROOT workshop, you will find several news items that might ease your pain.

Cheers, Axel.

I tried to build ROOT6 with ROOT7 support and it failed.

  • ROOT: root-master from github mirror
  • OS: ubuntu 15.10 (wily)
  • packages: cmake make cmake-curses-gui clang libc++-dev \ python-dev \ liblzma-dev libpcre3-dev libftgl-dev \ libx11-dev libxpm-dev libxft-dev libxext-dev libglu1-mesa-dev \
  • cmake command line: cmake -Droot7=On -Dcxx14=On
  • compilation error:

[ 47%] Generating G__Core.cxx, ../../lib/libCore.rootmap In file included from input_line_9:6: In file included from /workdir/root7/include/TTabCom.h:40: In file included from /workdir/root7/include/TObjString.h:28: In file included from /workdir/root7/include/TString.h:41: In file included from /workdir/root7/include/RStringView.h:24: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/experimental/string_view:39: /usr/bin/../lib/gcc/x86_64-linux-gnu/5.2.1/../../../../include/c++/5.2.1/bits/c++14_warning.h:32:2: error: This file requires compiler and library support for the forthcoming ISO C++ 2014 standard. This support is currently experimental, and must be enabled with the -std=c++1y or -std=gnu++1y compiler options.

It seems that -Dcxx14=On doesn’t enable -std=c++14 flag.


I have created - I agree that this should have worked…

I’m looking forward to your feedback!

Cheers, Axel.

It seems that the problem was with clang. gcc builds.

Plans for ROOT7 look interesting, a few question about those:

[li] Are there plans to improve build modularity further and use-as-library aspects for ROOT7?[/li]
[li] Will basic types such as Color_t remain unchanged or would it be possible e.g. to easily and reliably set any RGBa value directly through SetLineColor()?[/li]
[li] Finally get the pointer-to-integer conversions right and 64-bit Windows build?[/li][/ul]

Hi, Axel

I’m a bit confused now #-o . I’ve just successfully built root7 with clang. So both gcc and clang build it. Probably there was my mistake somewhere. I think you should close bugreport.

What do you mean exactly with this statement:

You would like be able to do obj->SetLineColor(r,g,b,a);


[quote=“couet”]You would like be able to do obj->SetLineColor(r,g,b,a);
Or perhaps a Color-object would be better suited as it allows single function definition for any kind of color definition.

The idea comes from a practical problem which could be descriped as follows:
one needs to periodically draw input-defined rgba-colors, maybe hundreds of them at once with reasonable performance, and instead of simply being able to do something like SetLineColor(TColor(r,g,b,a)), getting this done through TColor and Color_t seems(*) to involve modifying global color map (in non-thread safe manner?), dynamic memory allocations and worry of Color_t index space running out as the colors are input-defined.
While there are obviously reasons why the implementation is what it is and I’m not very well aware of those, the interface seems both cumbersome and even restrictive given what the underlying graphics systems may provide natively (e.g. in Qt one simply sets pen/brush color by QColor-object).

(*) Based on my understanding of ROOT5

Hi Berserker,

 I can try to hit somewhat. To have a context - I am a self learned c,c++ guy that uses root for analyses, analyses speed up and also in multithreaded processing and data readout from hw. A usual 1 of 10thousand users. And I didn't work with fortran that long to get a substantial damage.

 I can't really appreciate your systemic arguments, although they sound reasonable. But what I have is an opinion on gROOT, gPad, gFile, gDirectory etc.  

My typical approach is - 1/ I start an interpreter; 2/ I open some files; 3/ I open some canvases; 4/ I create some graphs, histos ... and ... I use my speedup macros to make small typical things on[b] current gPad in current gDir,gFile[/b] with one/few mouse-clicks:
  • just step-shift/zoom/unzoom a 1D or 2D histogram by a mouseclick;

  • make a contour with only a middle-mouse clicks, compute the sum immediately, create TGCut;

  • save/load/remove/rename gcuts in a file in ./

  • mark few points in a histogram - using Tgraph;

  • fit with my fitting function and draw the result back;

  • save the canvas/print it;

  • load the previously save pad and replace an old histo with an actual one;

  • divide the current canvas the way i like

  • switch to another file and work there

  • copy a histo to memory, cd to memory and see the same histograms from different files one-by-one

    instead of doing a thing many times in comandline, I better write it into a script and recall it on a mouse click. Why? I need to concentrate to the physics effects behind.

    What should I do, if all the gPad, gDirectory and gROOT->GetListOfSpecials() disappear? Ok, I throw away the macros, but what would be the other way to access a currently selected pad, file, global storage etc.? The CLI is very anthropocentric.