Why is g++ complaining?
up vote
0
down vote
favorite
Can somebody please explain this phenomenon?
#include <iostream>
int main()
And compile it, gaves:
g++ main.cpp -Dn=1
<command-line>:0:3: error: expected unqualified-id before numeric constant
And here is the complete video. I want to know the complete listing of these reserve thingy, and what they are. My environment is cygwin:
g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c++ g++
asked Nov 10 at 0:05
ifelsemonkey
539612
add a comment |
up vote
0
down vote
favorite
Can somebody please explain this phenomenon?
#include <iostream>
int main()
And compile it, gaves:
g++ main.cpp -Dn=1
<command-line>:0:3: error: expected unqualified-id before numeric constant
And here is the complete video. I want to know the complete listing of these reserve thingy, and what they are. My environment is cygwin:
g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c++ g++
asked Nov 10 at 0:05
ifelsemonkey
539612
iostreamdistributed with your compiler usesnsomewhere, and the only way to avoid it is not to#define nanywhere before including<iostream>.<iostream>shouldn't do do that (since, in C++,nis not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.
– Peter
Nov 10 at 3:35
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
Can somebody please explain this phenomenon?
#include <iostream>
int main()
And compile it, gaves:
g++ main.cpp -Dn=1
<command-line>:0:3: error: expected unqualified-id before numeric constant
And here is the complete video. I want to know the complete listing of these reserve thingy, and what they are. My environment is cygwin:
g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c++ g++
asked Nov 10 at 0:05
ifelsemonkey
539612
Can somebody please explain this phenomenon?
#include <iostream>
int main()
And compile it, gaves:
g++ main.cpp -Dn=1
<command-line>:0:3: error: expected unqualified-id before numeric constant
And here is the complete video. I want to know the complete listing of these reserve thingy, and what they are. My environment is cygwin:
g++ --version
g++ (GCC) 7.3.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
c++ g++
c++ g++
asked Nov 10 at 0:05
ifelsemonkey
539612
asked Nov 10 at 0:05
ifelsemonkey
539612
asked Nov 10 at 0:05
ifelsemonkey
539612
asked Nov 10 at 0:05
ifelsemonkey
539612
asked Nov 10 at 0:05
ifelsemonkey
539612
539612
iostreamdistributed with your compiler usesnsomewhere, and the only way to avoid it is not to#define nanywhere before including<iostream>.<iostream>shouldn't do do that (since, in C++,nis not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.
– Peter
Nov 10 at 3:35
add a comment |
iostreamdistributed with your compiler usesnsomewhere, and the only way to avoid it is not to#define nanywhere before including<iostream>.<iostream>shouldn't do do that (since, in C++,nis not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.
– Peter
Nov 10 at 3:35
iostream distributed with your compiler uses n somewhere, and the only way to avoid it is not to #define n anywhere before including <iostream>. <iostream> shouldn't do do that (since, in C++, n is not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.– Peter
Nov 10 at 3:35
iostream distributed with your compiler uses n somewhere, and the only way to avoid it is not to #define n anywhere before including <iostream>. <iostream> shouldn't do do that (since, in C++, n is not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.– Peter
Nov 10 at 3:35
add a comment |
1 Answer
1
active
oldest
votes
up vote
5
down vote
-Dn1 is defining n as a macro before iostream is included, which means it is redefining every occurrence of n in iostream as 1, which breaks a lot of stuff.
To fix it, pick a different macro name, or move the #define to inside the file after the include.
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
-Dn1 is defining n as a macro before iostream is included, which means it is redefining every occurrence of n in iostream as 1, which breaks a lot of stuff.
To fix it, pick a different macro name, or move the #define to inside the file after the include.
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
add a comment |
up vote
5
down vote
-Dn1 is defining n as a macro before iostream is included, which means it is redefining every occurrence of n in iostream as 1, which breaks a lot of stuff.
To fix it, pick a different macro name, or move the #define to inside the file after the include.
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
add a comment |
up vote
5
down vote
up vote
5
down vote
-Dn1 is defining n as a macro before iostream is included, which means it is redefining every occurrence of n in iostream as 1, which breaks a lot of stuff.
To fix it, pick a different macro name, or move the #define to inside the file after the include.
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
-Dn1 is defining n as a macro before iostream is included, which means it is redefining every occurrence of n in iostream as 1, which breaks a lot of stuff.
To fix it, pick a different macro name, or move the #define to inside the file after the include.
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
answered Nov 10 at 0:14
Ollin Boer Bohan
1,365310
1,365310
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
add a comment |
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
Huh? And how are we to avoid these collisions? Great, that it gave a compile error. Else, no compile errors, and it changes the underlying c++ library behavior. Do you know where to find the complete listings of these thingy? I like to dynamically defined my macro values at compilation time.
– ifelsemonkey
Nov 10 at 0:19
1
1
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
" I like to dynamically defined my macro values at compilation time." 1 - use all uppercase letters identifiers 2 - use longer names
– Slava
Nov 10 at 0:23
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
The only way to avoid collisions with macro substitutions is to not collide. Use better names and avoid macros.
– user4581301
Nov 10 at 0:29
add a comment |
draft saved
draft discarded
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53234836%2fwhy-is-g-complaining%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
iostreamdistributed with your compiler usesnsomewhere, and the only way to avoid it is not to#define nanywhere before including<iostream>.<iostream>shouldn't do do that (since, in C++,nis not a reserved identifier) but if it does your only option is to avoid using that macro name. It is rare in C++ to actually need to define/use any macro, since there are alternatives that are usually considered preferable. So your first option is not to use macros. If you insist on using macros (usually not a smart call) then either use different names or use a different compiler.– Peter
Nov 10 at 3:35