syntax of stringizing macro

[Siemel Naran]

#define EXPECT_ASSERT(x) { if (!x) expect_assert(localVariable, __FILE__,
__LINE__, #x); }

MSVC7 gives an error: "error C2014: preprocessor command must start as first
nonwhite space".

 

[Victor Bazarov]

#define EXPECT_ASSERT(x) { if (!x) expect_assert(localVariable, __FILE__,
__LINE__, #x); }

MSVC7 gives an error: "error C2014: preprocessor command must start as
first
nonwhite space".

If you want to span a macro over several lines of code, you _have_ to end
all
but the last with a \:

#define EXPECT_ASSERT(x) \
{ \
if (!x) \
expect_assert(localVariable, \
__FILE__, \
__LINE__, \
#x \
); \
}


V

 

[Pete Becker]

#define EXPECT_ASSERT(x) { if (!x) expect_assert(localVariable, __FILE__,
__LINE__, #x); }

MSVC7 gives an error: "error C2014: preprocessor command must start as first
nonwhite space".

Add a backslash at the end of the first line.

 

[Siemel Naran]

Add a backslash at the end of the first line.

Thanks. I guess by end of the first line you mean before the #x
(because different browsers/newsreaders page wrap differently). The
code below is two lines: line 1 starts with "#define" and ends with
"__LINE__, \", and line 2 starts with #x.

#define EXPECT_ASSERT(x) { if (!(x)) expect_assert(outputArgs,
__FILE__, __LINE__, \
#x); }

Anyway, is this behavior standard or Microsoft specific?

 

[Siemel Naran]

"Siemel Naran" <[email protected]> wrote...

#define EXPECT_ASSERT(x) \
{ \
if (!x) \
expect_assert(localVariable, \
__FILE__, \
__LINE__, \
#x \
); \
}

Thanks. This works, in addition to the suggestion Pete gave. Out of
curiosity, if have a macro

#define SOME_MACRO myfunction(__LINE__)

and we rewrite it as

#define SOME_MACRO myfunction( \
__LINE__)

will the line number passed to myfunction be the same in the following
program:

int main() { // line 10
SOME_MACRO; // will this call myfunction(10) or myfunction(11)?
}

Thanks.

 

[Victor Bazarov]

Thanks. This works, in addition to the suggestion Pete gave. Out of
curiosity, if have a macro

#define SOME_MACRO myfunction(__LINE__)

and we rewrite it as

#define SOME_MACRO myfunction( \
__LINE__)

will the line number passed to myfunction be the same in the following
program:

int main() { // line 10
SOME_MACRO; // will this call myfunction(10) or myfunction(11)?
}

Why don't you just try it?

Well, concatenation of lines with the \ between them happens _before_ any
macro substitution. Since __LINE__ is a macro, the substitution has to
happen _after_ the concatenation, so the 'SOME_MACRO' example you gave
should be considered as a single line. That's basically how you can make
your macro register where it was placed in the code. Of course it does
*not* prevent you from doing

SOME_MACRO; SOME_MACRO;

and have two calls with the same value at run time, since both macros get
the same __LINE__ substitution.

V

 

[Victor Bazarov]

Thanks. I guess by end of the first line you mean before the #x
(because different browsers/newsreaders page wrap differently). The
code below is two lines: line 1 starts with "#define" and ends with
"__LINE__, \", and line 2 starts with #x.

#define EXPECT_ASSERT(x) { if (!(x)) expect_assert(outputArgs,
__FILE__, __LINE__, \
#x); }

Anyway, is this behavior standard or Microsoft specific?

The Standard requires that if you want something after # to be interpreted
as a preprocessor directive, there has to be nothing between the beginning
of the line and the #, except whitespace. IOW, on any _separate_ line of
code, if the preprocessor sees only whitespace followed by #, it tries to
interpret what follows the # as the directive.

V

 

[Siemel Naran]

#define EXPECT_ASSERT(x) \
{ \
if (!x) \

Also, we have to use parenthesis around x, as it might be a sentence,
not a simple variable.

if (!(x)) \

 

[Old Wolf]

The code below is two lines: line 1 starts with "#define" and
ends with > "__LINE__, \", and line 2 starts with #x.

#define EXPECT_ASSERT(x) { if (!(x)) expect_assert(outputArgs,
__FILE__, __LINE__, \
#x); }

Anyway, is this behavior standard or Microsoft specific?

This has got to be a compiler bug. I guess you will get the
same result if you write:

#define foo \
#x)

FWIW do you get an error if you go:

#define foo \
#error Error!