无效的字符流宏
以下预处理器宏：
#define _VARIANT_BOOL /##/
实际上不是有效的C；粗略地说，原因是预处理器被定义为处理令牌流，而上面假设它处理字符流。
另一方面，不幸的是上面的内容实际上发生在 Microsoft 头文件中，所以无论如何我都必须处理它。 （我正在研究预处理器实现。）
人们在野外遇到过哪些其他情况，无论是在遗留代码中，只要该代码可能仍在使用，无论多么旧，预处理器宏实际上并不有效，但可以工作无论如何，因为它们是在使用面向字符的预处理器实现的编译器下编写的？
（理由：如果我编写一个正确、干净、符合标准的面向令牌的实现，我试图提前了解我将需要破解多少特殊情况。）
The following preprocessor macro:
#define _VARIANT_BOOL /##/
is not actually valid C; roughly speaking, the reason is that the preprocessor is defined as working on a stream of tokens, whereas the above assumes that it works on a stream of characters.
On the other hand, unfortunately the above actually occurs in a Microsoft header file, so I have to handle it anyway. (I'm working on a preprocessor implementation.)
What other cases have people encountered in the wild, be it in legacy code however old as long as that code may be still in use, of preprocessor macros that are not actually valid, but work anyway because they were written under compilers that use a character oriented preprocessor implementation?
(Rationale: I'm trying to get some idea in advance how many special cases I'm going to have to hack, if I write a proper clean standard-conforming token oriented implementation.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
标准
（§6.10.3.3 ##运算符）的相关部分表示：这意味着您的预处理器可以做任何它喜欢做的事情，并且仍然符合标准，包括模拟常见行为。
我认为您仍然可以拥有“基于令牌”的实现并支持此行为，方法是指定当
##运算符的结果不是有效的预处理令牌时，结果是两个操作数令牌不变。您可能还想让预处理器发出有关无效代码的警告。The relevant part of the standard
(§6.10.3.3 The ## operator)says:This means that your preprocessor can do anything it likes and still be standard conforming, including emulating the common behaviour.
I think you can still have a "token-based" implementation and support this behaviour, by specifying that when the result of the
##operator is not a valid preprocessing token, the result is the two operand tokens unchanged. You may also want to have your preprocessor emit a warning about the invalid code.