Compiling error: expected unqualified-id before numeric constant

852 views
Skip to first unread message

hill....@gmail.com

unread,
Nov 22, 2017, 8:25:58 PM11/22/17
to moose-users
   Compilation of some mudules,  such as phase_filed, solid_mechanics, at msys2 on windows fails with errores
---------------------------------------------------
expected unqualified-id before numeric constant
---------------------------------------------------

  I found such errors are due to redefinition of macro _L, _P etc, which are supposed defined at ctype.h. Modify those variables name into _LL, _PP, for example, would solve those problems. But it is a little awkward. Are there smart way, such as by compiler option, to solve this problem?

  By the way, it should suggested not to use those simple variables name with one only letter to avoid such conflicts.


Cody Permann

unread,
Nov 27, 2017, 1:41:32 PM11/27/17
to moose...@googlegroups.com
There are probably ways of avoiding that error but why would Windows complain while Mac OS and Linux do not? Perhaps this is a problem with your compiler or Windows setup? I believe we've had people compiling on Windows successfully before. 

Note that we still don't have extensive support for Windows usage.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.
Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/e0b30ec2-a59d-443d-93bf-cd1084e810fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Daniel Schwen

unread,
Nov 27, 2017, 4:46:35 PM11/27/17
to moose...@googlegroups.com
You're probably the first person (at least that we heard from) who is trying to build under msys2! A few users have had good success building on the Linux Subsystem for Windows (Ubuntu on Win10). I suggest before we do crazy things like renaming variables to accommodate exotic toolchains with (expletive redacted) macro names, we add some conditional undefs ins some high up moose headers at the appropriate places.

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAK06EuUMaYx4dPkOcrpapVh_iQSSc2Y%3D6%2B8CBkq98rwqDczqwg%40mail.gmail.com.

Daniel Schwen

unread,
Nov 27, 2017, 4:55:59 PM11/27/17
to moose...@googlegroups.com
Please look into if undefing __MISC_VISIBLE (before ctype.h is included) helps avoiding this error. It looks like the _L etc. macro definitions can be suppressed that way.
Daniel

Daniel Schwen

unread,
Nov 27, 2017, 6:16:41 PM11/27/17
to moose...@googlegroups.com
Ugh, I missed a line. That is not going to work. 

Daniel Schwen

unread,
Nov 27, 2017, 6:32:22 PM11/27/17
to moose...@googlegroups.com
Soooooo... at this point I bet most MOOSE team members are like "why are we even bothering with this stupid windows stuff?!", but it turns out we are the ones who are wrong!
A quick look at the C++11 standard (ISO/IEC 14882:2003(E)) on page 327 under 17.4.3.1.2 "Global names" it says: 

Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (__) or begins with an underscore followed by an upper-
case letter (2.11) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.165)

The first bullet applies here (assuming "any use" includes macro definitions). Well, I hope Derek writes a flaming rebuttal to this, because otherwise we'd be in a bit of a pinch, as we have literally hundreds of member variable names violating this standards rule.  :-D

P.S.: The Eigen library (which we used) already bucked and renamed their symbols for this reason...

Cody Permann

unread,
Nov 27, 2017, 7:03:52 PM11/27/17
to moose...@googlegroups.com
Ugh... What a mess. I don't think we use "underscore cap" letter identifiers in the framework, but I know they are in the modules in several places. The other big problem I see is that we have leading underscore global variables in MOOSE but only a few of those. That could be easily fixed. 

To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CAPxoKqfik5yYCVg5TAEzAOYzGA-s_yoCqybysX%2BGv%3DKs2y9pqw%40mail.gmail.com.

Andrs, David

unread,
Nov 28, 2017, 10:25:08 AM11/28/17
to moose...@googlegroups.com
On Mon, Nov 27, 2017 at 4:32 PM, Daniel Schwen <dan...@schwen.de> wrote:
Soooooo... at this point I bet most MOOSE team members are like "why are we even bothering with this stupid windows stuff?!", but it turns out we are the ones who are wrong!
A quick look at the C++11 standard (ISO/IEC 14882:2003(E)) on page 327 under 17.4.3.1.2 "Global names" it says: 

Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore (__) or begins with an underscore followed by an upper-
case letter (2.11) is reserved to the implementation for any use.

Consider this code:

// violation of the standard (global name)
int _W;

class A {
  // this is fine (not a global name)
  int _K;
};

We do not do (1)*), we do (2).

The problem comes from the collision between preprocessor names and C++ identifiers. If I do `#define _K 1` at the beginning of the file, I am screwed. I would have the same problem even if I replaced `_K` with `ASDF`, which does not violate any of these rules for reserved global names.

*) At least to my knowledge. If we do, we can fix it by moving those into a namespace.

— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.165)

The first bullet applies here (assuming "any use" includes macro definitions). Well, I hope Derek writes a flaming rebuttal to this, because otherwise we'd be in a bit of a pinch, as we have literally hundreds of member variable names violating this standards rule.  :-D

P.S.: The Eigen library (which we used) already bucked and renamed their symbols for this reason...
On Mon, Nov 27, 2017 at 4:16 PM Daniel Schwen <dan...@schwen.de> wrote:
Ugh, I missed a line. That is not going to work. 

On Mon, Nov 27, 2017 at 2:55 PM Daniel Schwen <dan...@schwen.de> wrote:
Please look into if undefing __MISC_VISIBLE (before ctype.h is included) helps avoiding this error. It looks like the _L etc. macro definitions can be suppressed that way.
Daniel

On Mon, Nov 27, 2017 at 2:46 PM Daniel Schwen <dan...@schwen.de> wrote:
You're probably the first person (at least that we heard from) who is trying to build under msys2! A few users have had good success building on the Linux Subsystem for Windows (Ubuntu on Win10). I suggest before we do crazy things like renaming variables to accommodate exotic toolchains with (expletive redacted) macro names, we add some conditional undefs ins some high up moose headers at the appropriate places.

On Mon, Nov 27, 2017 at 11:41 AM Cody Permann <codyp...@gmail.com> wrote:
There are probably ways of avoiding that error but why would Windows complain while Mac OS and Linux do not? Perhaps this is a problem with your compiler or Windows setup? I believe we've had people compiling on Windows successfully before. 

Note that we still don't have extensive support for Windows usage.

On Wed, Nov 22, 2017 at 6:26 PM <hill....@gmail.com> wrote:
   Compilation of some mudules,  such as phase_filed, solid_mechanics, at msys2 on windows fails with errores
---------------------------------------------------
expected unqualified-id before numeric constant
---------------------------------------------------

  I found such errors are due to redefinition of macro _L, _P etc, which are supposed defined at ctype.h. Modify those variables name into _LL, _PP, for example, would solve those problems. But it is a little awkward. Are there smart way, such as by compiler option, to solve this problem?

  By the way, it should suggested not to use those simple variables name with one only letter to avoid such conflicts.


--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users+unsubscribe@googlegroups.com.

Daniel Schwen

unread,
Nov 28, 2017, 11:09:23 AM11/28/17
to moose...@googlegroups.com
David, check out the discussion here:

It makes the argument that the reserved symbol names from C99 are still reserved in C++(11). 
"All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."
(where identifiers are macros, variable, or function names)

Second paragraph in the C++ standard:
" C++ is a general purpose programming language based on the C programming language as described in ISO/IEC 9899:1990 Programming languages – C (1.2). In addition to the facilities provided by C, C++ provides additional data types, classes, templates, exceptions, namespaces, inline functions, operator overloading, function name overloading, references, free store management operators, and additional library facilities."
I think the standard could be clearer here...

To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "moose-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to moose-users...@googlegroups.com.

Visit this group at https://groups.google.com/group/moose-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/moose-users/CADJmAN-qnsLSUeWk7Bxxn6n4Wx2%2B-yZrYgrsO9i3HN5w_0qtmQ%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages