GHS C++：额外的分号诊断消息 - 目的？

Question

在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++，我从未在我使用过的任何其他编译器上遇到过这样的警告消息。是否有一些合理的解释说明为什么此警告会有所帮助，例如，是否存在此警告可能指示编程错误的特定情况？

Answer 1

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

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

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

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

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

Answer 2

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

肯定是大多数情况？

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

不过，我想不出一个例子。

但是那个宏最好这样写：

#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)