为什么这个C宏会导致语法错误？

Question

This is the first time I'm using macros in C and I'm trying to replace a large section of code that I'd normally place into a function with a macro. This is a part of an interrupt which will be used quite often and therefore I need to optimize it as much as I can. After reading the documentation, I've seen that the compiler doesn't support function inlining and I want to avoid the function call overhead.

The code itself sends data to a serial-in parallel-out shift register and as far as I can see, there's no shorter way to write the piece of code I need.

I'm using C18 compiler version 3.41 and MPLAB X IDE.

So here's the code I'm using in function form:

void first_one(void)
{
   //3 invisible zeroes
            LATBbits.LATB1=0; //data set to zero

            LATBbits.LATB0=1;//first clock
            LATBbits.LATB0=0;

            LATBbits.LATB0=1;//second clock
            LATBbits.LATB0=0;

            LATBbits.LATB0=1;//third clock
            LATBbits.LATB0=0;
            //end of invisible zeroes

            //two visible zeroes    
            LATBbits.LATB0=1;//first clock
            LATBbits.LATB0=0;

            LATBbits.LATB0=1;//second clock
            LATBbits.LATB0=0;
            //end of two visible zeroes

            LATBbits.LATB1=1;//Data is now one

            LATBbits.LATB0=1;
            LATBbits.LATB0=0;
            //one 

            LATBbits.LATB1=0;//Data is now zero

            LATBbits.LATB0=1;//first clock
            LATBbits.LATB0=0;

            LATBbits.LATB0=1;//second clock
            LATBbits.LATB0=0;

            //after this, everything should be in place
            LATBbits.LATB0=1;
            LATBbits.LATB0=0;
}

I've turned the function into this macro:

#define first_one() {  \
\
            LATBbits.LATB1=0;\               
                              \
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
                                \
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
                            \
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
            \                                
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
\
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
            \
            LATBbits.LATB1=1;\
\
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\    
\
            LATBbits.LATB1=0;\
             ^^^ The syntax error is here!
\
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
\
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
\
            LATBbits.LATB0=1;\
            LATBbits.LATB0=0;\
\
                     }

So what am I doing wrong?

Update : I removed the comments and am now getting a syntax error in a different location.

Answer 1

检查\\ tokens后没有空格，有些编译器为此发出编译错误。

Answer 2

Lines are spliced before comments are removed, so the \\ in \\//3 invisible zeroes does does not continue the line.

You need either to remove the comment or use a C-style comment ( /* 3 invisible zeroes */ ) and place the comment before the \\ that continues the line.

Answer 3

The problem is with the comments and the way the preprocessor deals with them. Remove the comments and this should work fine. Alternativly use /* Comment */

Answer 4

Three suggestions:

First, make sure that there aren't any trailing spaces after each \\ .

Second, drop the () from the macro name if it's not meant to take any arguments. edit struck per comments below.

Finally, wrap the contents of the macro in a do {...} while(0) (with no trailing semicolon). This way, when you write first_one(); in your code, you won't have a spurious semicolon after the closing brace.

In short,

#define do_first         \
  do {                   \
    LATBbits.LATB0 = 1;  \
    ...                  \
  } while(0)

edit Lundin points out that this is old-fashioned and unnecessary. I always believed it was required to avoid a diagnostic if a macro expanded to a statement of the form {...}; -- apparently I was wrong. I still prefer it as a stylistic choice, though.