_ATL_ALLOW_UNSIGNED_CHAR什么时候起作用? [英] When will _ATL_ALLOW_UNSIGNED_CHAR work?

问题描述

我正在将使用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在/J 的MSDN文档中提到了以及含糊的声明:如果您将此编译器选项与ATL/MFC一起使用，则可能会生成错误.尽管您可以通过定义_ATL_ALLOW_CHAR_UNSIGNED来禁用此错误，但不支持该替代方法，并且可能并不总是有效."

有人知道在什么情况下使用_ATL_ALLOW_CHAR_UNSIGNED是安全的还是不安全的?

解决方案

Microsoft努力使古老的代码库(如ATL)与编译器中的更改兼容.这里的主要麻烦制造者是 AtlGetHexValue() 函数.它有一个设计错误:

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

-1是9年前与/J断裂的摩擦.它实际上不会今天返回-1，现在如果使用/J进行编译，它将返回CHAR_MAX((char)255).由于将未签名的char与-1比较将始终为 false ，并且整个if()语句均被省略，因此是必需的.这就破坏了ATL本身，如果您使用此功能，也将以一种非常讨厌的方式破坏您的代码，因为该代码位于错误路径上，不太可能被测试.

射掉臀部，他们可以通过3种基本方法解决此问题.他们可能将返回值类型更改为 int ，冒着破坏所有人的风险.或者他们可能已经注意到MSDN文章中的特殊行为，使每个人都看不见.或者他们可以调用继续前进的时间"选项.他们选择的是那时候，那时MSVC ++成为了编程世界的笑柄.

这就是您需要从ATL担心的所有事情，使用此功能的可能性很小，而且很容易找回.否则，一个很好的提示可以帮助您寻找可能会从自己的代码中遇到的麻烦.

I'm migrating a Visual C++ project which uses ATL/MFC from VS2010 to VS2013. The project compiles with /J ("assume char is unsigned"), and there is too much code that may or may not rely on that fact to easily remove the compiler flag.

Under VS2013, /J causes a compiler error in atldef.h: ATL doesn't support compilation with /J or _CHAR_UNSIGNED flag enabled. This can be suppressed by defining _ATL_ALLOW_UNSIGNED_CHAR. Microsoft mention this in the MSDN documentation for /J, along with the vague statement: "If you use this compiler option with ATL/MFC, an error might be generated. Although you could disable this error by defining _ATL_ALLOW_CHAR_UNSIGNED, this workaround is not supported and may not always work."

Does anyone know under what circumstances it is safe or unsafe to use _ATL_ALLOW_CHAR_UNSIGNED?

解决方案

Microsoft struggles to keep ancient codebases, like ATL, compatible with changes in the compiler. The principal trouble-maker here is the AtlGetHexValue() function. It had a design mistake:

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 is the rub, 9 years ago that broke with /J in effect. And it won't actually return -1 today, it now returns CHAR_MAX ((char)255) if you compile with /J. Required since comparing unsigned char to -1 will always be false and the entire if() statement is omitted. This broke ATL itself, it will also break your code in a very nasty way if you use this function, given that this code is on the error path that is unlikely to get tested.

Shooting off the hip, there were 3 basic ways they could have solved this problem. They could have changed the return value type to int, risking breaking everybody. Or they could have noted the special behavior in the MSDN article, making everybody's eyes roll. Or they could have invoked the "time to move on" option. Which is what they picked, it was about time with MSVC++ being the laughing stock of the programming world back then.

That's about all you need to fear from ATL, low odds that you are using this function and easy to find back. Otherwise an excellent hint to look for the kind of trouble you might get from your own code.

这篇关于_ATL_ALLOW_UNSIGNED_CHAR什么时候起作用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！