C++ std symbols polluting cling

[ccorti]

Dear experts,

when using the interpreter, C++ std symbols pollute the namespace, even if I set Rint.Includes: 0 in .rootrc.
An example:

root [0] int data = 1
(int) 1
root [1] data = 2
ROOT_prompt_1:1:1: error: reference to 'data' is ambiguous
data = 2
^
ROOT_prompt_0:1:5: note: candidate found by name lookup is '__cling_N50::data'
int data = 1
    ^
/usr/include/c++/11/bits/range_access.h:319:5: note: candidate found by name lookup is 'std::data'
    data(initializer_list<_Tp> __il) noexcept
    ^
/usr/include/c++/11/bits/range_access.h:290:5: note: candidate found by name lookup is 'std::data'
    data(_Container& __cont) noexcept(noexcept(__cont.data()))
    ^
/usr/include/c++/11/bits/range_access.h:300:5: note: candidate found by name lookup is 'std::data'
    data(const _Container& __cont) noexcept(noexcept(__cont.data()))
    ^
/usr/include/c++/11/bits/range_access.h:310:5: note: candidate found by name lookup is 'std::data'
    data(_Tp (&__array)[_Nm]) noexcept
    ^
root [2] __cling_N50::data
(int) 1

Prefixing __cling_N50:: every time is really cumbersome, not to mention that the specific __cling namespace changes during the interactive session.
However, this is even worse if a C++ name is used as name for a TNamed-derived object:

root [0] 
Attaching file Rates_V0_flux.root as _file0...
(TFile *) 0x556c10f0ab20
root [1] .ls
TFile**		Rates_V0_flux.root	
 TFile*		Rates_V0_flux.root	
  KEY: TTree	data;1
  KEY: TNtuple	bins;1
root [2] data
ROOT_prompt_2:1:1: error: reference to overloaded function could not be resolved; did you mean to call it?
data
^~~~
/usr/include/c++/11/bits/range_access.h:290:5: note: possible target for call
    data(_Container& __cont) noexcept(noexcept(__cont.data()))
    ^
/usr/include/c++/11/bits/range_access.h:300:5: note: possible target for call
    data(const _Container& __cont) noexcept(noexcept(__cont.data()))
    ^
/usr/include/c++/11/bits/range_access.h:310:5: note: possible target for call
    data(_Tp (&__array)[_Nm]) noexcept
    ^
/usr/include/c++/11/bits/range_access.h:319:5: note: possible target for call
    data(initializer_list<_Tp> __il) noexcept
    ^
root [3] bins
(TNtuple *) 0x556c10cd9c40

Now the TTree data is not available at all, the only way of using it is to do auto t = gFile->Get<TTree>("data").
In previous versions of ROOT (like 6.20), I had similar problems with variable names like y, but I never had problems with TTrees called data.

Best,
Claudio

---

ROOT Version: 6.26/02
Git Revision: c8d49336
Platform: Ubuntu
Compiler: gcc

---

[eguiraud]

Hi @ccorti ,

thank you for the report and sorry for the high latency, this must have slipped through the cracks.

This is a known annoyance with C++17 builds of ROOT, as that’s the C++ version in which std::data was introduced, and the interpreter has an implicit using namespace std;.

There was some discussion about this at Ambiguous 'data' in global scope .

@Axel did anything change since then?

Cheers,
Enrico

[Axel]

Woops sorry, my fault, this slipped through indeed.

Unconditionally removing using namespace std will break the world. Yet I don’t know of any other solution here. Would a root --puns (“prevent using namespace std”) be a viable workaround for you? This will actually be quite some work to implement, we know because we tried in the past: there’s a lot of ROOT code that stems from CINT times and relies on finding vector and friends. So before embarking there I’d like to see whether that would be a reasonable approach.

[Wile_E_Coyote]

Well, this is a know nuisance.

How about instead of injecting “using namespace std;”, you inject a precisely described set of “using std::vector;” and “using std::friends;” (and so on for everything you need, and only for that).

BTW. A similar unsolved deficiency: “MakeClass and std::”

[ccorti]

Well, there is already a system in place to avoid to automatically include std headers: Rint.Includes in rootrc.
I would expect that if I explicitly ask ROOT not to include any std header, then using namespace std should never happen automatically.

[Axel]

Rint.Includes: 0 isn’t as effective with C++ modules-based dictionaries, which make “everything” available through a different mechanism.

I’ll look at a use of only certain types from std.