visual-c++ - _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 来抑制。 .微软提到这个 in the MSDN documentation for /J ，以及含糊的声明:“如果您将此编译器选项与 ATL/MFC 一起使用，则可能会生成错误。尽管您可以通过定义 _ATL_ALLOW_CHAR_UNSIGNED 来禁用此错误，但此解决方法不受支持，并且可能并不总是有效。”

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

Answer 1

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

The numeric value of the input character interpreted as a hexadecimal digit. For example, an input of '0' returns a value of 0 and an input of 'A' returns a value of 10. If the input character is not a hexadecimal digit, this function returns -1.

-1 是 9 年前与/J 失效的摩擦。而且它今天实际上不会返回 -1，如果使用/J 编译，它现在返回 CHAR_MAX ((char)255)。必需，因为将 unsigned char 与 -1 进行比较将始终为 false，并且省略整个 if() 语句。这破坏了 ATL 本身，如果您使用此函数，它也会以非常讨厌的方式破坏您的代码，因为此代码位于不太可能经过测试的错误路径上。

从臀部射击，他们可以通过 3 种基本方法解决这个问题。他们本可以将返回值类型更改为 int，从而冒着破坏所有人的风险。或者他们可以注意到 MSDN 文章中的特殊行为，让每个人都翻白眼。或者他们可以调用“时间继续前进”选项。这是他们选择的，是时候让 MSVC++ 成为编程世界的笑柄了。

这就是您需要担心的 ATL 的全部内容，您使用此功能的几率很低，而且很容易找回来。否则，这是一个很好的提示，可以寻找您可能从自己的代码中遇到的麻烦。