What is the # for when formatting using %s

Question

I came across this example of an assertion and was wondering what the # is for:

#define ASSERT( x ) if ( !( x ) ) { \
    int *p = NULL; \
    DBGPRINTF("Assert failed: [%s]\r\n Halting.", #x); \
    *p=1; \
  } 

Distinct

Answer 1

It is the "stringize" preprocessing operator.

It takes the tokens passed as the argument to the macro parameter x and turns them into a string literal.

#define ASSERT(x) #x

ASSERT(a b c d)
// is replaced by
"a b c d"

Manikin

Answer 2

#x is the stringification directive

#define Stringify(x) #x

means Stringify(abc) will be substituted with "abc"

as in

#define initVarWithItsOwnName(x) const char* p = #x

int main()
{
   initVarWithItsOwnName(Var);
   std::cout << Var; //will print Var
}

Laetitia

Answer 3

# is the preprocessor's "stringizing" operator. It turns macro parameters into string literals. If you called ASSERT(foo >= 32) the #x is expanded to "foo >= 32" during evaluation of the macro.

Sometime

Answer 4

It's a preprocessor feature called stringification. It

replaces [the macro parameter] with the literal text of the actual argument, converted to a string constant.

Lise

Answer 5

# is the stringizing operator defined in Section 6.10.3.2 (C99) and in Section 16.3.2. (C++03)

It converts macro parameters to string literals without expanding the parameter definition.

If the replacement that results is not a valid character string literal, the behavior is undefined. The order of evaluation of # operator is unspecified.

For instance, syntactically, occurrences of the backslash character in string literals are limited to escape sequences.

In the following example:

1        #define  mkstr(x)  #  x
2        char  *p  =  mkstr(a  \  b);  
       /*  "a  \  b"  violates  the  syntax  of  string  literals  */

the result of the # operator need not be "a \ b".

Getz

Are there any circumstances under which "the replacement that results is not a valid character string literal"? I can't think of any. – Manikin

@James McNellis : Found an example in "The New C Standard", check out my post. – Getz

Interesting. My understanding of "the spelling of the preprocessing token sequence" (from C++) is that the compiler needs to perform any necessary escaping, so mkstr("a") would yield "\"a\"", not ""a"". Perhaps that does not apply to extraneous non-whitespace tokens? – Manikin

No that doesn't get applied to extraneous whitespace tokens. This would be fine IMHO mkstr(a\b). No exraneous whitespace. – Getz

@Prasoon: What I meant was that `` on its own is a "non-whitespace character" token. It's not an operator-punctuator and doesn't fit into any of the other preprocessing token types. So it seems that the only time the behavior could be undefined is when you have a preprocessing token that cannot be converted into a token after preprocessing (there is no preprocessing token-to-real token mapping for non-whitespace character tokens). – Manikin

While I agree about the example producing undefined behavior, I find it curious: my understanding was that the stringize operator was responsible for fully escaping tokens that needed to be fully escaped, e.g. "\\" becomes "\"\\\\\"". – Manikin

Answer 6

It's the stringizing operator.

http://msdn.microsoft.com/en-us/library/7e3a913x(v=vs.80).aspx

Histrionic

Answer 7

What you see is called stringification. It allows you to convert an argument of a macro into a string literal. You can read more about it here http://gcc.gnu.org/onlinedocs/cpp/Stringification.html.

Resect