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

[baumann]

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]

"baumann@pan" <ba*********@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

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]

In article <11**********************@z14g2000cwz.googlegroups .com>,
baumann@pan <ba*********@gmail.com> wrote:

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]

In article <mn***********************@YOURBRAnoos.fr>,
Emmanuel Delahaye <em***@YOURBRAnoos.fr> wrote:

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.

That's usually true in practice -- but it's not part of the
standard ;-)
--
"Who Leads?" / "The men who must... driven men, compelled men."
"Freak men."
"You're all freaks, sir. But you always have been freaks.
Life is a freak. That's its hope and glory." -- Alfred Bester, TSMD

[Richard Bos]

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote:

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

_Pre_processor.

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.

Richard

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

"Emmanuel Delahaye" <em***@YOURBRAnoos.fr> wrote:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Emmanuel Delahaye]

Mark McIntyre wrote on 15/04/05 :

On Fri, 15 Apr 2005 06:15:37 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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.

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]

On Fri, 15 Apr 2005 21:31:37 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

Mark McIntyre <ma**********@spamcop.net> writes:

On Fri, 15 Apr 2005 06:15:37 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

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.

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".)

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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Mark McIntyre]

On Sat, 16 Apr 2005 08:39:58 +0200, in comp.lang.c , "Emmanuel
Delahaye" <em***@YOURBRAnoos.fr> wrote:

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++...

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...
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

[Keith Thompson]

Mark McIntyre <ma**********@spamcop.net> writes:

On Fri, 15 Apr 2005 21:31:37 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

[...]

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.

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Mark McIntyre]

On Sun, 17 Apr 2005 20:34:18 GMT, in comp.lang.c , Keith Thompson
<ks***@mib.org> wrote:

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".
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>