hi why can not i us #if in the macro?

[baumann@pan]

hi all,

what's the problem of the macro below?

#define COMMENT_LINE(p) \
#if 0\
(p);\
#endif

when i compiled it in vs.net, it complains

c99.cpp(12) : error C2162: formal paramer of macro needed
c99.cpp(17) : error C2059: syntax error : "constant"
c99.cpp(17) : error C2065: "endif" : undeclared symbol


i don;t know why.

 

[Alex Fraser]

what's the problem of the macro below?

#define COMMENT_LINE(p) \
#if 0\
(p);\
#endif

You cannot use preprocessor directives in a #define. That is just the way
the language is defined. If you explain what you are trying to achieve,
maybe someone can suggest an alternative solution.

Alex

 

[Richard Tobin]

what's the problem of the macro below?

#define COMMENT_LINE(p) \
#if 0\
(p);\
#endif

You seem to be expecting the macro to expand into something containing
the #if directive, but it doesn't work like that.

The lines are pasted together first, producing

#define COMMENT_LINE(p) #if 0 (p);#endif

which is syntactically incorrect.

-- Richard

 

[Emmanuel Delahaye]

baumann@pan wrote on 11/04/05 :

what's the problem of the macro below?

#define COMMENT_LINE(p) \
#if 0\
(p);\
#endif

This is not C. You can't have proprocessor thingies in macros (# is
already used for something else).

when i compiled it in vs.net, it complains

c99.cpp(12) : error C2162: formal paramer of macro needed

Your extension should be .c if you intent to compile a C source.

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Walter Roberson]

when i compiled it in vs.net, it complains
c99.cpp(12) : error C2162: formal paramer of macro needed

[/QUOTE]

Your extension should be .c if you intent to compile a C source.

That's usually true in practice -- but it's not part of the
standard ;-)

 

[Richard Bos]

baumann@pan wrote on 11/04/05 :

This is not C. You can't have proprocessor
_Pre_processor.


Your extension should be .c if you intent to compile a C source.

Depends on the compiler, surely? With gcc, this is true, but that means
nothing for any other compiler.

Richard

 

[Keith Thompson]

baumann@pan wrote on 11/04/05 : [...]

when i compiled it in vs.net, it complains

c99.cpp(12) : error C2162: formal paramer of macro needed

Your extension should be .c if you intent to compile a C source.

Depends on the compiler, surely? With gcc, this is true, but that means
nothing for any other compiler.

Most C compilers (all the ones I know of) use ".c" as the normal
suffix for C source files; ".cpp" is probably C++. Yes, it depends on
the compiler, but it's a widespread convention.

 

[Mark McIntyre]

On Fri, 15 Apr 2005 06:15:37 GMT, in comp.lang.c ,

Depends on the compiler, surely? With gcc, this is true, but that means
nothing for any other compiler.

microsoft copmilers assume its C++ unless its suffix is .c. Some sun
compilers differentiate between .C and .c.

Yuck.

 

[Keith Thompson]

On Fri, 15 Apr 2005 06:15:37 GMT, in comp.lang.c ,


microsoft copmilers assume its C++ unless its suffix is .c. Some sun
compilers differentiate between .C and .c.

Somewhat OT, but most Unix compilers use ".c" for C source and either
".C" or ".cpp" for C++ source. (Windows compilers don't use ".C" for
C++ because the file system can't distinguish between ".C" and ".c".)

 

[Emmanuel Delahaye]

Mark McIntyre wrote on 15/04/05 :

On Fri, 15 Apr 2005 06:15:37 GMT, in comp.lang.c ,


microsoft copmilers assume its C++ unless its suffix is .c. Some sun
compilers differentiate between .C and .c.

Eclipse/CDT for example...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"C is a sharp tool"

 

[Emmanuel Delahaye]

Keith Thompson wrote on 15/04/05 :

Somewhat OT, but most Unix compilers use ".c" for C source and either
".C" or ".cpp" for C++ source. (Windows compilers don't use ".C" for
C++ because the file system can't distinguish between ".C" and ".c".)

Windows XP does, and you must be careful when using Eclipse/CDT,
because .C invokes g++...

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

..sig under repair

 

[Mark McIntyre]

Somewhat OT, but most Unix compilers use ".c" for C source and either
".C" or ".cpp" for C++ source. (Windows compilers don't use ".C" for
C++ because the file system can't distinguish between ".C" and ".c".)

that should read "couldn't, prior to about 1999". All modern windows
OSen can do this quite handily, though the command interpreter still
is too stupid.

 

[Mark McIntyre]

Keith Thompson wrote on 15/04/05 :

Windows XP does, and you must be careful when using Eclipse/CDT,
because .C invokes g++...

the reason I mentioned this is because we just got bitten on the a*se
by precisely this 'bug'. We ported a library back from Solaris to XP,
and the compile kept falling over mysteriously...

 

[Keith Thompson]

On Fri, 15 Apr 2005 21:31:37 GMT, in comp.lang.c , Keith Thompson


that should read "couldn't, prior to about 1999". All modern windows
OSen can do this quite handily, though the command interpreter still
is too stupid.

Still a bit OT ...

Yes, Windows distinguishes between ".c" and ".C", but not in the same
way that Unix does. A file name retains whatever case was specified
when it was created, but you can't have two files in the same
directory named "foo.c" and "foo.C"; if you have a file called
"foo.c", you can successfully open it either as "foo.c" or as "foo.C".

Presumably this means that you can compile a given source file either
as C or as C++ just by changing the name by which you refer to it
(without actually changing the name of the file). (I say "presumably"
because I don't actually use Windows compilers.) Not a huge deal, but
something to watch out for.

To make it topical, all this stuff affects the semantics of fopen(),
which is part of the reason the C standard doesn't say much about what
file names look like other than being strings.

 

[Mark McIntyre]

Yes, Windows distinguishes between ".c" and ".C", but not in the same
way that Unix does. A file name retains whatever case was specified
when it was created, but you can't have two files in the same
directory named "foo.c" and "foo.C"; if you have a file called
"foo.c", you can successfully open it either as "foo.c" or as "foo.C".

FWIW I seem to recall that you can, but creating them via the
high-level functions or command line gui is pretty tricky.

Presumably this means that you can compile a given source file either
as C or as C++ just by changing the name by which you refer to it
(without actually changing the name of the file). (I say "presumably"
because I don't actually use Windows compilers.) Not a huge deal, but
something to watch out for.

In fact no - all the compilers I know of are case-insensitive when it
comes to filenames. This hs coincidentally how I know of this issue -
we had some C++ we ported from solaris & linux back to windows, and a
couple of files didn't compile properly with gcc. Turned out they were
named ".C".