"Bad character" error w/ C++11 syntax

ROOT
1

I’ve just started getting an error where there was none before, and cannot figure why. Specifically, I get the following error whenever I try to use a {} initializer list with an argument that contains a - sign:

Error: Variable name has bad character ‘RMin{-5,-5,-5}’ Recon.hh:38:
Internal warning: RMin{-5,-5,-5} comment can not set Recon.hh:38:

No error occurs if I write something like

vector RMin {5, 5, 5};

i.e. if I remove the minus signs. The problem also happens with strings, depending on how I initialize them. I can write these

string Particle = “e-”;
string Particle {“e”};

However, I get an error for

string Particle {“e-”};

Worst of all, this wasn’t happening two days ago. I manually retyped the offending file, but with no luck. My guess is that I accidentally changed a setting on my editor (ST3), but if so I don’t know how. Everything I’ve checked, e.g. the character encoding (UTF-8), is the same as before.

Any help appreciated!

2

Why don’t you tell us your ROOT version + attach the smallest sample file reproducing your problem?
If you’re using pre-cling ROOT - you can use C++11 features (actually, this means C++ features nowadays) - only “ACLiCked” (AFAIK).
CINT does not parse modern C++. If you’re using the cling version, please, attach your code.

P.S. Ok, I see now, you are trying to use C++ 11 constructs with CINT. Event if it silently accepts
vector b{1,2,3} - it means nothing - CINT does not understand “new” C++ syntax and how he interprets this declaration - is yet another mystery. Either switch to cling (ROOT 6 beta) or ACLiC your code or avoid using C++11 syntax.

3

Yes, some more info would be useful…can’t believe I neglected that. I’m running 5-34-11 on OS X 10.9, on an early 2013 rMBP. I’ve been using ACLiC exclusively, with the .L MyCode.cxx+ command, then MyCode(args). I’ve been using a fair amount of C++11 syntax for several weeks now, and this is the first time it’s given me any trouble.

I’ve experimented further, and the trouble seems to come from using C++11 syntax, in a struct/class definition, sometimes.

I get errors when I use C++11 syntax, e.g double d {3};, in a struct/class def in a macro file. (See MyMacro.cxx and Error1.txt). If I remove that struct class def and put it in a header file MyStruct.h, then #include the header file in MyMacro.cxx, there’s no trouble. Further, I can successfully define something like double d {-3}; in the macro file itself (outside the struct def).

However, if I try to to use C++11 syntax and a - sign in the header file – e.g. change the variable in the struct def from from double d {3}; to double d {-3}; – I get a different error (see Error2.txt).

It seems Root doesn’t want C++11 syntax in a struct/class definition, unless it’s in a header file that’s #included in a second file. However, you can’t combine - signs with C++11 syntax in a struct/class def, even if that def comes in a header file. All C++11 syntax, even with - signs, is fine outside a struct/class def. At least that’s my current (limited) understanding…

Update: 5-34-14 gives me the same results.
MyStruct.h (155 Bytes)
MyMacro.cxx (313 Bytes)
Error2.txt (909 Bytes)
Error1.txt (851 Bytes)

4

As I’ve already explained, CINT (in your ROOT 5.34) does not understand ‘new’ syntax from C++11. Even if it does not generate an error with {3} (and generates with {-3}) - it DOES NOT MEAN CINT can interpret C++11 code.
For example, CINT “understands” this:

but not really:

[quote]root[1]d

Error: Symbol d is not defined in current scope (tmpfile):1:[/quote]

Either switch to ROOT 6/cling configured/built with C++11 enabled, or do not use C++11.
I remember in the past I was able to use C++11 in ACLiCked code with a lot of ifdefs and tricks hiding the ‘new’ code from CINT and not from clang, but this is not a solution really, since you’ll: 1) have a lot of redundant code just to exclude CINT from work, and as a consequence - 2) still have a very limited support.

5

I’m misunderstanding the role CINT. I’m not writing any code during an interactive session, i.e. in the manner of your examples. I’m only loading/compiling my code with the .L MyCode.cxx++ command, which I thought obviated the use of CINT as an interpreter. That’s based on my (apparently flawed) reading of Section 7.9 of the user’s guide:

“Instead of having CINT interpret your script there is a way to have your scripts compiled, linked and dynamically loaded using the C++ compiler and linker…you can use language constructs that are not fully supported by CINT.”

I understand your point that CINT doesn’t interpret C++11 syntax. However, I thought that would be a non-issue – i.e. CINT wouldn’t be used to interpret any code – for code compiled, linked, and loaded via the .L command. In my experience, C++11 syntax has worked just fine when used in this fashion, and that’s without “tricks” of any kind. Furthermore, I’ve been able to successfully use constructs like double vd {-1, 2}; in other macros, as recently as this morning.

Obviously I can avoid C++11 syntax in ROOT 5.xx.xx, if needed. What I don’t appreciate is how CINT’s limitations in interpreting code play a role when compiling with the .L MyCode.cxx++ command.

6

[quote=“patrickm”]…

That’s based on my (apparently flawed) reading of Section 7.9 of the user’s guide:

“Instead of having CINT interpret your script there is a way to have your scripts compiled, linked and dynamically loaded using the C++ compiler and linker…you can use language constructs that are not fully supported by CINT.”

I understand your point that CINT doesn’t interpret C++11 syntax. However, I thought that would be a non-issue – i.e. CINT wouldn’t be used to interpret any code – for code compiled, linked, and loaded via the .L command. In my experience, C++11 syntax has worked just fine when used in this fashion, and that’s without “tricks” of any kind. Furthermore, I’ve been able to successfully use constructs like double vd {-1, 2}; in other macros, as recently as this morning.

[/quote]

One more time: CINT (== macros == interpreted mode) does not support any of C++11 syntax.

void noway() { vector<int> v{1,2,3}; std::cout<<v.size()<<std::endl; }

[quote]root [0] .x noway.C
Error: Symbol v is not defined in current scope noway.C:4:
Error: Failed to evaluate v.size()
(class G__CINT_ENDL)140613809887664
*** Interpreter error recovered *[/quote]

The same documentation you quoted also mentions, that CINT is still used to generate a dictionary for you class. You can hide some difficult parts from CINT.

But even if you hide the code from CINT completely using
#ifndef CINT or something like this, still you have another problem - compiler invoked by ACLiC procedure (clang in your case) must compile with -std=c++11 to work.

root.cern.ch/download/doc/ROOTUs … s/CINT.pdf:

[quote]1.9.4 Intermediate Steps and Files
ACLiC executes two steps and a third one if needed. These are:
• Calling rootcint to create a CINT dictionary. rootcint is a ROOT specific version of makecint, CINT generic
dictionary generator.
• Calling the compiler to build the shared library from the script
• If there are errors, it calls the compiler to build a dummy executable to report clearly unresolved symbols.
ACLiC makes a shared library with a CINT dictionary containing the classes and functions declared in the script. It
also adds the classes and functions declared in included files with the same name as the script file and any of the
following extensions: .h, .hh, .hpp, .hxx, .hPP, .hXX. …
[/quote]

7

I could add that I’ve been able to use some C++11 features with "++"ed code, but list initialization has never worked for me. I needed to do some magic with the MakeSharedLib and other ACLiC variables, for which I wrote an easily-broken set of macros (attached below).

I tried very hard to get list initialization (and the uniform initialization syntax) to work with ROOT, but so far I’ve heard combinations of:
a) Wait for ROOT6
b) OSX 10.7 can’t do it, you need 10.9 (but you have that) because of C++ runtime things
c) Stop using C++11
d) Stop using ROOT

I’m using ROOT (5.34) on OSX 10.7 from MacPorts, built using the clang 3.2 compiler (also from MacPorts).

Jean-François
SetACLiC.C (2.98 KB)

8

Thanks for the feedback. I have consistently been able to use C++11 features like list initialization and the uniform {} initialization syntax. (I compiled ROOT with the --enable-cxx11 and --enable-libcxx options, among others.) So until a few days ago, CINT didn’t cause me any trouble. That’s why I thought its limitations had been overcome.

9

Right, since I use ROOT from MacPorts, I don’t have direct control over the compile-time switches. Apparently --enable-cxx11 and --enable-libcxx are turned on if you use 10.9 (and a recent enough compiler), since 10.9 uses libc++. 10.7 and 8 have libc++ somewhere, but don’t use it by default, so MacPorts ignores that and turns off C++11 support for ROOT.