您可以设计一个简单的宏来在使用时有效地产生编译器错误吗? [英] Can you devise a simple macro to effectively produce a compiler error when used?

问题描述

我正在寻找一个奇怪的宏定义，目的是:我需要以这种方式定义一个宏，如果该宏有效地用于编译后的代码中，则编译器将毫无疑问地产生错误.

I am looking for a strange macro definition, on purpose: I need a macro defined in such a way, that in the event the macro is effectively used in compiled code, the compiler will unfailingly produce an error.

背景:由于C11引入了几个新的关键字，并且新的C ++ 11标准也添加了一些关键字，因此我想在我的项目中引入头文件(主要使用C89/C95编译器，并添加一些内容)迫使开发人员不要将这些新关键字用作标识符名称，除非它们以预期的方式被识别为关键字.

The background: Since C11 had introduced several new keywords, and a new C++11 standard also added a few, I would like to introduce a header file in my projects (mostly using C89/C95 compilers with a few additions) to force developers to refrain from using these new keywords as identifier names, unless, of course, they are recognized as keywords in the intended fashion.

在古代，我是这样为new这样做的:

In the ancient past, I did this for new like this:

#define new *** /* C++ keyword, do not use */

是的，它奏效了.直到不是这样，当程序员忘记了参数名称中的下划线时:

And yes, it worked. Until it didn't, when a programmer forgot the underscore in a parameter name:

void myfunction(uint16_t new parameter);

此后，我使用了变体，但再也没有受到挑战.

I used variants since, but I've never been challenged again.

现在，我打算创建一个文件，其中包含各种编译器不支持的所有关键字，并且我正在寻找一种可靠的解决方案，充其量是避免出现过于混乱的错误消息. 语法错误"可以，但是参数缺失"已经很令人困惑.
我正在考虑

Now I intend to create a file with all keywords not supported by various compilers, and I'm looking for a dependable solution, at best with a not too confusing error message. "Syntax error" would be OK, but "parameter missing" would be confusing already.
I'm thinking along the lines of

#define atomic +*=*+ /* C11 derived keyword; do not use */

除了我通常的犹豫之外，我很确定对宏的任何使用(而不是定义)都会产生错误.

and aside from my usual hesitation, I'm quite sure that any use (but not the definition) of the macro will produce an error.

要使其更加困难，MISRA将只允许使用基本的源代码和执行字符集，因此不允许使用@或$.

To make it even more difficult, MISRA will only allow the use of the basic source and execution character set, so @ or $ are not allowed.

但是我想问社区:您是否具有更好的宏观价值?一样有效，但是较短?甚至更长，但在某些奇怪的情况下更可靠?还是一种完全不一样的方法，当出于任何目的使用不适当的"标识符时，会产生错误(请仅使用编译器，而不是外部工具！)?

But I'd like to ask the community: Do you have a better macro value? As effective, but shorter? Or even longer but more dependable in some strange situation? Or a completely different method to generate an error (only using the compiler, please, not external tools!) when a "discouraged" identifier is used for any purpose?

免责声明: 而且，是的，我知道我可以使用grep或解析器在夜间构建中运行，并报告发现的警告.但是，将即时错误放到开发人员桌面上的速度更快，而且一定可以在签入之前解决.

Disclaimer: And, yes, I know I can use a grep or a parser to run on a nightly build, and report the warnings it finds. But dropping an immediate error on the developers desk is quicker, and certain to be fixed before checking in.

推荐答案

如果这项运动是针对总是产生错误的最短令牌序列，则两个合法的字符运算符的任意组合都不能合法出现，但是

If the sport is for the shortest tokensequence that always produces an error, any combination of two 1 character operators that can't legally occur together, but

• 请勿使用({或})，因为gcc具有特殊含义
• 请勿使用任何不平衡的括号，因为它们会导致您走得很远，直到错误被识别出为止
• 请勿使用<或>，因为它们可以匹配C ++的模板参数
• 请勿将前缀运算符用作第二个字符
• 请勿将后缀运算符用作第一个字符

• don't use ({ or }) because gcc has a special meaning for that
• don't use any sort of unbalanced parentheses because they can lead you far away until the error is recognized
• don't use < or > because they could match template parameters for C++
• don't use prefix operators as second character
• don't use postfix operators as first character

这留下了一些可能性

• ..，.|和其他与.的组合，因为.需要以下标识符
• &|，&/，&^，&,，&;
• !|，!/，!^，!,，!;

• .., .| and other combinations with . since . expects a following identifier
• &|, &/, &^, &,, &;
• !|, !/, !^, !,, !;

但是实际上，为了更方便用户使用，我还要先在其中放置_Pragma，这样编译器也会吐出警告.

But actually to be more user friendly I'd also first place a _Pragma in it so the compiler would also spit a warning.

#define atomic _Pragma("message \"some instructive text that you should read\"") ..

这篇关于您可以设计一个简单的宏来在使用时有效地产生编译器错误吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！