Strange behaviour related to dictionary


ROOT shows some strange behaviour using template member functions that I don’t understand. It’s a bit complicated to explain, so I will make a short example. Suppose you have a class looking like this:

[code]class MyClass
type GetScalar(TString alias)
[some code here]


For making this available in interpreted mode, I use a linkdef with statements like the following:

This compiles fine. On the ROOT commandline I now do something like

MyClass& test = GetMyClassReferenceFromSomewhere(); test.GetScalar<Int_t>("Name");

I get an error like

Error: Symbol test is not defined in current scope (tmpfile):1: Error: Failed to evaluate test.GetScalar Error: Symbol Int_t is not defined in current scope (tmpfile):1: Error: > Illegal operator for pointer 3 (tmpfile):1:

And it also won’t work in any subsequent call. The strange thing is, as soon as I type test. and press the TAB key, or I call any other (non template) member function, the GetScalar calls suddenly work.

Do you have an explanation for this behaviour? I’m using v5.16.

Thanks for you help.


do you load the library containing MyClass before calling “test.GetScalar<Int_t>(“Name”);”?


Yes I do.

Can you please provide a complete running example showing this problem?


Here you go. To reproduce the bug, start ROOT, load the library, then do the following:

MyClass& m = GetMyClassReference(); m.GetScalar<Int_t>("Test");

Remember not to press TAB while typing that!

It seems to have something to do with the reference. The following works:

MyClass m; m.GetScalar<Int_t>("Test");

dictionary_bug.tar.gz (13 KB)


I can reproduce the problem. The issues is the late dictionary loading feature of CINT (important to prevent wasting RAM on dictionary you are not using) which is not triggered in your exact case (aka a reference data member and a function name including template parameters).

We are currently overhauling the Cint code and this problem will be addressed once we are done with this overhauling.

Thanks for reporting this problem.

PS. This item is tracked at


This problem is fixed by revision 32879 in the trunk.