我正在将一个使用 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 是安全的还是不安全的?

最佳答案

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



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

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

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

关于visual-c++ - _ATL_ALLOW_UNSIGNED_CHAR 什么时候起作用?,我们在Stack Overflow上找到一个类似的问题:https://stackoverflow.com/questions/27246149/

10-11 22:50
查看更多