_ATL_ALLOW_UNSIGNED_CHAR何时起作用？

Question

我正在迁移一个Visual C++项目,该项目使用从VS2010到VS2013的ATL/MFC.项目编译/J("假设char是无符号的"),并且有太多代码可能依赖或不依赖于该事实来轻松删除编译器标志.

在VS2013下,在atldef.h中/J导致编译器错误:ATL doesn't support compilation with /J or _CHAR_UNSIGNED flag enabled.这可以通过定义来抑制_ATL_ALLOW_UNSIGNED_CHAR.Microsoft 在MSDN文档中/J提到了这一点以及模糊的声明:"如果将此编译器选项与ATL/MFC一起使用,则可能会生成错误.虽然您可以通过定义_ATL_ALLOW_CHAR_UNSIGNED来禁用此错误,但不支持此解决方法,并且可能并不总是有效."

有谁知道在什么情况下使用它是安全的还是不安全的_ATL_ALLOW_CHAR_UNSIGNED？

Answer 1

微软努力保持古老的代码库(如ATL)与编译器的变化兼容.这里的主要麻烦制造者是AtlGetHexValue()函数.它有一个设计错误:

输入字符的数值被解释为十六进制数字.例如,输入"0"返回值0,输入"A"返回值10.如果输入字符不是十六进制数字,则此函数返回-1.

-1是摩擦,9年前与/ J打破了效果.它今天实际上不会返回-1,如果用/ J编译,它现在返回CHAR_MAX((char)255).因为将unsigned char与-1进行比较,所以必须始终为false,并且省略整个if()语句.这打破了ATL本身,如果你使用这个函数,它也将以非常恶劣的方式破坏你的代码,因为这个代码是在不太可能被测试的错误路径上.

从臀部射击,有3种基本方法可以解决这个问题.他们本可以将返回值类型更改为int,从而有可能打破每个人.或者他们可以注意到MSDN文章中的特殊行为,让每个人都眼前一亮.或者他们可以调用"继续前进的时间"选项.这就是他们选择的内容,当时MSVC++是当时编程世界的笑柄.

这就是你需要担心的所有ATL,你使用这个功能并且容易找回的几率很低.否则,这是一个很好的提示,可以查找您可能从自己的代码中获得的麻烦.