Question

Microsoft的MIDL编译器生成稍微无效的C / C ++源代码文件，如此摘录中的代码：

#ifndef CLSID_DEFINED
#define CLSID_DEFINED
typedef IID CLSID;
#endif // CLSID_DEFINED

#define MIDL_DEFINE_GUID(type,name,l,w1,w2,b1,b2,b3,b4,b5,b6,b7,b8) \
        const type name = {l,w1,w2,{b1,b2,b3,b4,b5,b6,b7,b8}}

#endif !_MIDL_USE_GUIDDEF_

Visual C ++忽略#endif之后的标记，但神圣标准不需要任何内容，因此g ++出错，甚至gcc（编译为C）都会产生警告：

H:\dev\tools\better keyboard\test>gcc com_server\com_server_i.c -c
com_server\com_server_i.c:68:8: warning: extra tokens at end of #endif directive
 #endif !_MIDL_USE_GUIDDEF_
        ^

H:\dev\tools\better keyboard\test>_

每次生成代码时手动修复代码都会让人感到厌烦和烦恼。

是否有更好的方法可以避免这个明显未命名的警告，假设gcc必须编译代码？

我看过existing question roughly about this，但无济于事。

Answer 1

^{将评论转换为答案。}

最简单的机制可能是对生成的代码进行后处理：

sed -i.bak -e 's/^#endif .*/#endif/' com_server/com_server_i.c

或同等学历。或者您可以在#endif之后保留材料，但在那里发表评论：

sed -i.bak -e 's%^#endif \(.*\)%#endif // \1%' com_server/com_server_i.c

如果你使用的是makefile，那么在调用MIDL编译器之后将后处理添加为额外的操作非常容易。

交叉引用的问题不会有帮助;宏定义无法删除!。实际上，即使宏扩展为空，#endif之后宏的存在也会引发警告。

您是否检查过MIDL编译器的Microsoft错误报告（以查看它是否是一个他们拒绝解决的已知问题）？你有没有检查MIDL编译器的选项，看看是否有什么可以解决这个问题？

在预处理指令后避免（生成的）令牌的gcc警告？

1 个答案: