我正在迁移使用从VS2010到VS2013的ATL / MFC的Visual C ++项目。该项目使用/J编译（＆＃34;假设char未签名＆＃34;），并且有太多代码可能依赖或不依赖于该事实来轻松删除编译器标志。< / p>
在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以及模糊的声明：＆＃34;如果在ATL / MFC中使用此编译器选项，则可能会生成错误。虽然您可以通过定义_ATL_ALLOW_CHAR_UNSIGNED来禁用此错误，但不支持此解决方法，并且可能无法始终有效。＆＃34;
有谁知道在什么情况下使用_ATL_ALLOW_CHAR_UNSIGNED安全或不安全？
答案 0 :(得分：6)
微软努力保持古老的代码库（如ATL）与编译器的变化兼容。这里的主要麻烦制造者是AtlGetHexValue()功能。它有一个设计错误：
输入字符的数值被解释为十六进制数字。例如，输入＆＃39; 0＆＃39; 0返回值0和输入＆＃39; A＆＃39;返回值10.如果输入字符不是十六进制数字，此函数返回-1 。
-1是摩擦，9年前与/ J打破了效果。它今天实际上不会返回-1，如果用/ J编译，它现在返回CHAR_MAX（（char）255）。因为将unsigned char与-1进行比较将始终为 false 并且省略整个if（）语句。这打破了ATL本身，如果您使用此函数，它也会以非常讨厌的方式破坏您的代码，因为此代码位于不太可能被测试的错误路径上。
射击时尚，有三种基本方法可以解决这个问题。他们本可以将返回值类型更改为 int ，从而有可能打破每个人。或者他们可以注意到MSDN文章中的特殊行为，让每个人都眼前一亮。或者他们可以调用'＃34;时间继续前进＆＃34;选项。这就是他们选择的内容，当时MSVC ++是当时编程世界的笑柄。
关于ATL需要担心的一切，你使用这个功能并且容易找回的几率很低。否则，这是一个很好的提示，可以查找您可能从自己的代码中获得的麻烦。