在编译器中导致错误

哦，当然，这有道理！（愚蠢的我不记得宏观！）



      以下为原文

    Oh sure, that makes sense! (stupid of me not remembering about the macro!)

这不是编译器中的一个bug，它并不是一个错误，它不能被修改，因为“（100）”只是一个与Y.E.DelayuUS无关的表达式。C不要求语句在单独的行上，而您所拥有的是同一行上的两个语句：γ-DelayuUS（US）计算为复合语句{……一些代码…}和（100）；是表达式语句。所以你有：{……一些代码…}（100），相当于……一些代码…（100）；当然，（100）；什么也不做。



      以下为原文

   
 
This is not a bug in the compiler, and it's not a bug in __delay_us, and it can't be "fixed" by changing __delay_us, because "(100)" is just an expression that has nothing to do with __delay_us.  C does not require statements to be on separate lines, and what you have is two statements on the same line:  __delay_us(us) evaluates to the compound statement { ...some code... } and (100); is an expression statement.  So what you have is:
 
{ ...some code... } (100);
 
which is equivalent to
 
...some code... ;
(100);
 
and of course the (100); does nothing.

当然，寺庙是正确的。这里是宏的定义：& lt；编辑& gt；如果宏没有括号和分号定义，它仍然应该工作，并且将为此情况生成一个错误。



      以下为原文

    Of course @jtemples is correct. Here is the definition of the macro:
#define __delay_us(d)
  { __delay32( (unsigned long) (((unsigned long long) d)*(FCY)/1000000ULL)); }

 
If the macro is defined without the braces and the semicolon, it should still work and will generate an error for this case.
 
 

永远记住，C是包含无限量的绳子的语言，不需要额外收费。



      以下为原文

    Always remember, C is the language that includes an infinite amount of rope at no extra charge.

…一个刽子手套索（我上传一个图像，但访问被拒绝）。



      以下为原文

   
... a hangmans noose  (I'd upload an image but Access is Denied).

严肃地说，宏不应该用括号和分号来定义吗？



      以下为原文

   
Seriously though, shouldn't the macro be defined without the braces and semicolon?
#define __delay_us(d)
  __delay32( (unsigned long) (((unsigned long long) d)*(FCY)/1000000ULL))

所以，当然是背带的过错和内疚…



      以下为原文

    So it was the braces' fault and guilt of course...

嗯，它不是通常的“安全措施”，当它被用于复合语句或类似的时候？（我也不喜欢他们……）



      以下为原文

   


Well, isn't it the usual "safety measure" for when it's used in compound statements or alike? (I don't like them either...)

我不认为这是个问题，因为γ-Delay32（）定义为：



      以下为原文

   
I don't see that is a problem because __delay32() is defined as:
extern void __delay32(unsigned long cycles);

谢谢，那么我相信我的观点是：1）我想要的是：但是我得到了：（100）是一个法律声明，除了我不知道为什么编译器没有抱怨失踪；在这两个声明之间？2）允许把这样的东西放入任何代码中：它将被接受C代码但不做任何事情…我的代码停止工作的原因必须是因为延迟比预期的短100倍。它现在正在工作，我的问题是编译器没有帮助的原因。我发现了。主要是PASCAL开发人员，我对C缺乏检查感到不安。很容易射出一只脚……但是，在任何情况下，如果我忘记在使用它们之前声明我的变量，那就好像是C30，这很好！



      以下为原文

    Thanks, then I believe my take from this is:
1) what I wanted was:
__delay_us(100);
but I got instead:
__delay_us(1)
(100);
where (100) is a legal statement, except I am wondering why the compiler did not complain about the missing ; between the two statements?
2) It is allowed to put something like this into the code anywhere:
(100);
and it will be accepted C code but does not do anything...
 
The reason my code ceased to work must be because the delay became 100 times shorter than intended.
It is now working and my question was really why the compiler did not help me spot it. Being primarily a Pascal developer I am uncomfortable with the C lack of checking. Easy to shoot ones foot....
 
However it seems like C30 in any case errors out if I forget to declare my variables before using them, that is good!
 

因为宏计算为{代码…这在语法上是一个语句，就像……代码…；是一个语句。



      以下为原文

   
 
Because the macro evaluates to { ...code...  } which syntactically is a statement, just like ...code...; is a statement.

对于像这样的单个语句宏，我通常不会麻烦用括号包装它。但我不认为C30的操作有什么“错误”，虽然更典型的是，如果你想包装宏，它是用“do{…代码…”完成的。}（0）“（在结束时没有分号）。这也会引发宏错误，因为宏调用缺少分号。



      以下为原文

   
 
For a single-statement macro like that, I usually wouldn't bother wrapping it in braces.  But I wouldn't say there's anything "wrong" with what C30 does, though more typically if you want to wrap a macro, it's done with "do { ...code... } while (0)" (no semicolon at the end).  That would have also triggered a syntax error due to the missing semicolon on the macro invocation.

同意。也许Microchip应该编辑宏定义。



      以下为原文

   
Agree. Perhaps Microchip should edit that macro definition.