Exposed global variable in cling

Raymond_Beuselinck · January 15, 2025, 6:10pm

A simple variable name created in a ROOT interactive session clashes unexpectedly with a variable exposed by Cling.
Seen in ROOT 6.34.02
Built for linuxx8664gcc on Dec 25 2024, 00:00:00
From tags/6-34-02@6-34-02
Standard version from fedora repository for fedora 41.

To reproduce.

Just run ROOT
see commands and output copied below.
root [1] auto x1 = 5.0;
root [2] x1
(double) 5.0000000
root [3] auto y1 = 7.0;
root [4] y1
ROOT_prompt_4:1:1: error: reference to ‘y1’ is ambiguous
y1
^
ROOT_prompt_3:1:6: note: candidate found by name lookup is ‘__cling_N52::y1’
auto y1 = 7.0;
^
/usr/include/bits/mathcalls.h:239:13: note: candidate found by name lookup is ‘y1’
__MATHCALL (y1, (Mdouble));
^
root [5]

Why should a simple variable name like y1 cause a problem?

Wile_E_Coyote · January 15, 2025, 7:17pm

ferhue · January 16, 2025, 8:41am

Related issues:

github.com/root-project/root

Comment by ferdymercury - [metacling] remove redundant 'using namespace std' since std is autoinjected later in TClingUtils

root-project:master ← ferdymercury:nostd

> I think we should not rely on this side effect, the explicit `using namespace …std` that we have right now is better. I understand. Feel free to close this PR in that case. I just thought, if at some point, someone tries to restart with https://github.com/root-project/root/pull/11027, there was one line less to worry about. Speaking about 11027 and potential ways to slowly going away from global std, from my point of view, it would be nice to have something equivalent to this config variable: ``` # You can set the variable below to 0 to disable the loading of these # includes at startup. You can set the variable to 1 (default) to load # only <iostream>, <string> and <DllImport.h>. You can set it to 2 to # load in addition <vector> and <utility>. We strongly recommend setting # the variable to 2 if your scripts include <vector> and you execute # your scripts multiple times. Rint.Includes: 1 ``` So, one could have this interpreter behavior: `Rint.NamespaceStd` is 2 by default and calls `using namespace std;` If you set it to 1, it just calls `using std::string, std::cout, std::endl, std::vector, std::cerr, std::cin, std::array;` If you set it to 0, you need to do things correctly as in a C++ program. In ROOT 6.42 one could set the default to 1, and in ROOT 9 set the default to 0 ;) This could be independent on dictionary generation, I guess, that could stay as before with full namespace std statement.

github.com/root-project/root

The implicit `using namespace std;` can have nasty side effects on Windows.

opened 01:15PM - 06 Feb 24 UTC

bellenot

in:Core Libraries

### Check duplicate issues. - [X] Checked for duplicates ### Description … As described [on the forum](https://root-forum.cern.ch/t/building-cling-dll-from-source-code/55311/9) trying to '#include <atlstr.h>` in ROOT create a lot of errors: ``` root [0] #include <atlstr.h> In file included from ROOT_prompt_0:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlstr.h:19: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlbase.h:66: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlcore.h:25: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\Ole2.h:37: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\objbase.h:16: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h:192:9: error: reference to 'byte' is ambiguous typedef byte cs_byte; ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h:191:23: note: candidate found by name lookup is 'byte' typedef unsigned char byte; ^ C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\cstddef:28:12: note: candidate found by name lookup is 'std::byte' enum class byte : unsigned char {}; ^ In file included from ROOT_prompt_0:1: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlstr.h:19: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlbase.h:66: In file included from C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\ATLMFC\include\atlcore.h:25: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\Ole2.h:37: In file included from C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\um\objbase.h:16: C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h:962:6: error: reference to 'byte' is ambiguous byte * pNetworkData, ^ [...] C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\cstddef:28:12: note: candidate found by name lookup is 'std::byte' enum class byte : unsigned char {}; ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] root [1] ``` To illustrate this, compiling this code: ``` #include <iostream> using namespace std; #include <atlstr.h> int main() { std::cout << "hello world!" << std::endl; return 0; } ``` is enough to generate the errors: ``` C:\Users\bellenot\rootdev>cl -nologo -MD -GR -EHsc -Zc:__cplusplus -std:c++17 atlstr.cxx atlstr.cxx C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h(192): error C2872: 'byte': ambiguous symbol C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h(191): note: could be 'unsigned char byte' C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\cstddef(28): note: or 'std::byte' C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h(962): error C2872: 'byte': ambiguous symbol C:\Program Files (x86)\Windows Kits\10\include\10.0.19041.0\shared\rpcndr.h(191): note: could be 'unsigned char byte' C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\cstddef(28): note: or 'std::byte' [...] ``` And when removing the `using namespace std;` line, there is no error ### Reproducer On Windows: ``` root [0] #include <atlstr.h> ``` ### ROOT version Any ### Installation method build from source ### Operating system Windows ### Additional context _No response_

github.com/root-project/root

[TCling] C++-use string,vector instead of std.

root-project:master ← Axel-Naumann:using-things-instead-of-using-namespace-std

opened 01:35PM - 22 Jul 22 UTC

Axel-Naumann

+164 -145

Current state: - the normalized name continues to remove `std::` - it injects …using declarations for the "most common" stdlib identifiers - this PR adds `std::` where "needed", to the normalized name, to make identifiers "compilable" (in dictionary source). The last point requires to have an authoritative list of "things in the std namespace", to prepend `std::` to them. This does not scale - any stdlib implementation might have any non-public identifier that might be needed also for public types, e.g. some libstdc++ have `std::thread::id` as type alias to `std::__thread_id`. Alternatively, this PR could implement a "if lookup fails, try again with prepending `std::`". This is an issue for types such as `foo<bar, baz<boo,boz>>` where either any type must be tested for std-ization separately or all possible permutations (`std::foo<bar, baz<boo,boz>>`, `foo<std::bar, baz<boo,boz>>`,`std::foo<std::bar, baz<boo,boz>>`...) must be tried.

system · January 30, 2025, 8:41am

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.