_ATL_ALLOW_UNSIGNED_CHAR 什么时候可以工作？

Question

我正在将一个使用 ATL/MFC 的 Visual C++ 项目从 VS2010 迁移到 VS2013。该项目使用/J 进行编译（“假设char 是未签名的”），并且有太多代码可能会或可能不会依赖该事实来轻松删除编译器标志。

在 VS2013 下，/J 导致 atldef.h 中的编译器错误：ATL doesn't support compilation with /J or _CHAR_UNSIGNED flag enabled。这可以通过定义_ATL_ALLOW_UNSIGNED_CHAR 来抑制。 Microsoft 提到了这个in the MSDN documentation for /J，以及模糊的声明：“如果您将此编译器选项与 ATL/MFC 一起使用，可能会生成错误。虽然您可以通过定义 _ATL_ALLOW_CHAR_UNSIGNED 来禁用此错误，但此解决方法不受支持并且可能并不总是工作。”

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

Answer 1

Microsoft 努力使 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 的全部内容，您使用此功能的几率很低并且很容易找回。否则，这是寻找您自己的代码可能遇到的麻烦的绝佳提示。