2013-10-29 27 views
4

这个程序“CTYPE” 功能引发的std :: bad_cast

#include <iostream> 
#include <locale> 

int main() { 
    std::isxdigit(std::cin.peek(), std::cin.getloc()); 
} 

当用gcc或使用铿锵++的libstdc编译对我抛出std::bad_cast类型的异常。它通常与VS2010一起运行。

我明白这里发生了什么。 peek()返回int以适应带外EOF值。语言环境不需要具有ctype<int>构面(它们在VS中具有此方面,可能作为扩展)。如果语言环境没有执行功能的方面,则会抛出bad_cast

但是,不应该按照原始<ctype.h>的精神工作吗?这是标准中的缺陷吗?是否有一个普遍接受的解决方法?我知道我可以自己检查EOF并投射到相关的字符类型,但我宁愿不要重新发明轮子。

回答

1

否:必须知道字符类型(假定32位int是具有用于EOF的64位表示的字符类型)。它无法解析,语言环境不受特定字符类型的约束,但它的方面是。

有:

std::isxdigit<char>(std::cin.peek(), std::cin.getloc()); 

将澄清通话,而忽略EOF使其CHAR(INT(-1))(!)。

因此,你可能会自己检查EOF。

+0

曾经有一种习惯于使用'ctype'函数和EOF。我明白为什么这个习语在现场土地上不起作用。我问,标准委员会成员是否知道他们在破产时做了什么,以及他们或其他人是否想到替代方案。用EOF检查器包装这些功能的解决方案不会让我感到特别优雅。如果每个人都需要包装这些功能,为什么包装版本不是标准的一部分? –