I had searched in the Discussion Forum for the whole moring but I couldn't find the right way to solve the problem I met,so I send this message hoping you guys can help me!Thanks in advance:-)My problem is as follows: 1.I want to define a macro,which is similar like function.It will be used in my communction interrupt service routine(so you can see that why I don't choose to call a function to realize it) 2.here's the definition of this macro: #define Macro_TestRxEnd(sbit Header_flag,uchar Header,uchar Tailer) \ { \ Return_flag = 0; \ if (!Header_flag) \ { \ if (Rxbuf == Header) \ { \ Header_flag = 1; \ ptRxBuf++; \ } \ else \ { ptRxBuf = xBuf; } \ else \ { \ if (Rxbuf == Tailer) \ { Return_flag = 1; } \ } 3.then the compile result is : Error C304: Bad Macro Parameter List so can anyone help me find out the right way to define such a long macro? I'm waiting for your good ideas earnestly!
Remember that a macro is implemented by text substitution - a macro parameter list doesn't need (or accept) data types.
This is basic 'C' stuff - nothing specifically to do with Keil! "I want to define a macro,which is similar like function" This is really quite dangerous. Macros can look like functions, but behave very differently - there are many pitfalls, some of which are discussed in K&R. "It will be used in my communction interrupt service routine (so you can see that why I don't choose to call a function to realize it)" No, I don't see that at all. There is a general rule-of-thumb that one should try to keep Interrupt Service Routines (ISRs) "small" - meaning that the amount of code executed during the interrupt service should be minimised. Putting your code into a Macro will not help in this respect! In fact, If the code is so large that you think you need a macro for it, the overhead of calling a function is probably insignificant! "3.then the compile result is : Error C304: Bad Macro Parameter List" Of course it's bad: open your 'C' textbook - macro parameters do not have type specifiers! As I said, macros can be dangerous because they look like functions, but don't behave like functions. You have already fallen into one such trap before you've even started - do you really want to dig yourself (and the rest of your team, and their successors) more traps to fall into...? I think you should re-think your approach!
View all questions in Keil forum