用fscanf - comma代替point的愚蠢bug

Question

我的一个项目的c++源代码中有一个愚蠢的bug。我在源I/O操作的这一部分做。我有一个愚蠢的bug，我打印fscanf read的值。首先，我没有读取好的值，当我打印一个浮点值时，我得到的是一个带有逗号的十进制值，而不是一个点。整数部分和浮点部分之间。

FILE* file3;
file3=fopen("test.dat","r");
float test1;
fscanf(file3," %f ",&test1);
printf("here %f\n",test1);
float test3 = 1.2345;
printf("here %f\n",test3);
fclose(file3);        

其中test.dat文件包含"1.1234“，我在执行时得到：

here 1,000000
here 1,234500

所以，我用g++编译了一个简单的C程序：

#include <stdio.h>
#include <stdlib.h>

int main()
{
  FILE* file3;
  float test3;
  file3=fopen("test.dat","r");
  fscanf(file3,"%f",&test3);
  printf("here %f\n",test3);
  fclose(file3);
}

它提供了：

here 1.123400

这是我第一次遇到这样的bug。有没有人能看出来出了什么问题？

Answer 1

您的C++语言环境是否以某种方式设置为使用欧洲约定？他们使用逗号，我们使用点和点作为千的分隔符。

看看环境变量的设置

LANG LC_CTYPE LC_ALL

尝试设置en_GB或en_US。在确定这是一个场所问题之后，接下来决定什么行为是有意义的。播放1224,45到底是不是一个bug？用户设置语言环境是有原因的。

Answer 2

您使用的代码使用的是针对程序环境设置的语言环境。在某些语言环境中，例如在讲法语的语言环境中，逗号是小数点分隔符。因此，这段代码所做的事情大概是它的语言环境告诉它的。

在您的简单代码中，您没有初始化区域设置支持，因此这种情况不会发生。

假设一个类Unix的环境，环境变量LANG和各种LC_*环境变量的值是什么？

环境| grep -e ^LANG -e ^LC_

要获得一些背景知识，请尝试一些GNU Libc手册(本地化和国际化)

http://www.gnu.org/software/libc/manual/html_node/Locales.html#Locales

Answer 3

我的猜测是，应用程序使用std::locale::global( std::locale( "" ) )将区域设置设置为用户的首选项。这就是控制台应用程序应该做的事情；它们还应该向std::cin、std::cout和std::cerr灌输这种语言环境。大多数语言社区使用逗号作为小数点，而不是点。(对于后台进程，使用"C"区域设置或Unix下的"Posix"区域设置通常更合适，而不管服务器实际运行在何处。由于"C"语言环境是默认语言环境，因此对于后台程序和服务器，什么也不做通常是可以接受的。)

全局区域设置会影响所有C样式的输入和输出，这也是使用C++的iostream的另一个原因。在std::ifstream中，只需在进行第一次输入之前将编写文件时所使用的区域设置灌输给流即可。对于机器生成的文件，"C"区域设置是通常的默认设置，因此您的代码将如下所示：

std::ifstream file3( "test.dat" );
if ( ! file3.is_open() ) {
    //  error handling...
}
file3.imbue( std::locale( "C" ) );
float test1;
file3 >> test1;
//  ...

对于到终端的输出，期望遵循区域设置约定。并设置环境变量以指定要查看的区域设置。