0

在GHS编译器中，如果连续有多个分号而没有任何中间语句，则会生成诊断消息（警告）。例如：

void myfunc()
{
}; // warning #381-D: extra ';' ignored.

这似乎不是一个很常见的情况，但是在预处理发生后也会发出此警告，这样，以下内容也会产生警告（在发布时编译时）：

#if _DEBUG
  #define DEBUG_VAR(x) x
#else
  #define DEBUG_VAR(x) 
#endif

void myfunc()
{
}
// global variable, used only in debug
DEBUG_VAR(int x); // warning #381-D: extra ';' ignored.

我意识到在这种情况下有一些简单的方法可以解决这个问题，这只是一个说明性的例子。预处理器还有许多其他情况，您最终可能会得到类似的构造。

显然，代码是合法的 c++，而且我从未在我使用过的任何其他编译器上遇到过这样的警告消息。是否有一些合理的解释为什么这个警告会有所帮助，例如，是否存在这个警告可能表明编程错误的特定情况？

4

2 回答 2

0

我最喜欢的例子是“持久分号”。我们在我最后一个工作的地方有一个。他不止两次写道：

for (i=0; i<MAX; ++i);
    a[i] = 0;

...然后因为他的数组没有初始化而受到阻碍。更糟糕的是，他有一个随机变量被破坏的错误。

如果你不能发现它，如果编译器发现它不是很好吗？

说了这么多，我同意一个杂散的分号通常是“驯服的”——但是让编译器在一个地方吐出错误的逻辑并没有区分其他地方......

于 2016-09-12T11:44:47.420 回答
-3

是否有一些合理的解释为什么这个警告会有所帮助，例如，是否存在这个警告可能表明编程错误的特定情况？

大多数情况下，确定吗？

由于;没有任何意义，要么你把它写成冗余（然后你必须问“为什么？”）或者——这是关键——你写它是通过不小心删除它之前的一些代码，或者因为其他地方出错而写的这使解析器感到困惑，并使其; 看起来像是多余的，而实际上并非如此。

不过，在我的脑海中，我想不出一个例子。

但是那个宏最好这样写：

#include <type_traits>
#ifndef NDEBUG
   #define DEBUG_VAR(T, N) std::common_type<T>::type N;
#else
   #define DEBUG_VAR(T, N)
#endif

void myfunc()
{}

// global variable, used only in debug
DEBUG_VAR(int, x)
于 2015-05-19T13:56:06.697 回答