为什么我的程序在Windows和Linux上产生不同的结果,有关ifstream的文件读取? [英] Why does my program produce different results on Windows and Linux, about file reading with ifstream?

查看:151
本文介绍了为什么我的程序在Windows和Linux上产生不同的结果,有关ifstream的文件读取?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个程序如下所示。对我有几个问题:



1)。 为什么在不同的平台上产生不同的结果?稍后我会粘贴屏幕截图。



2)。 我使用一个fail()方法来检查file.read()是否失败。这是否正确?我使用fail()方法,因为说:


返回 true 如果在关联的流上发生错误。具体来说,如果 badbit failbit 设置为,则返回 true rdstate()


而C ++标准说:


返回 true 如果failbit或 badbit rdstate()


没有文件结束之外的东西。尝试读取超过文件末尾的操作将导致 failbit 也被设置。 eofbit 仅用于区分具体的失败原因与其他原因(并且这不是一开始可能想到的有用)。







我使用 fail()方法检查 file.read()失败。这是正确的吗?


您只需测试转换为 bool / p>

  if(file){//文件不处于错误状态
pre>

它是!fail()的同义词,但它更有用,因为您可以使用它来直接测试没有额外括号的读操作的结果(例如!(stream>> x).fail() get awkward):

  if(file.read(fileBuf,fileLen)){//读取成功

您会注意到,所有对流的读取操作都会返回流本身,这是允许您这样做的。







为什么在不同平台上产生不同的结果?


在Windows和Linux之间看到的差异是因为文件在文本模式下打开:换行字符将被实现静默地转换。这意味着\r\\\
(在Windows中用于换行符)将被转换为单个'\\\
'
字符,使文件只有8个字符。注意vim如何在第一行结尾处显示 ^ M :这是'\r'部分。在Linux中,换行符只是'\\\
'



要保留原来的原样:

  file.open(path,std :: ios_base :: in | std :: ios_base :: binary); 


I have a program shown as follows. For it I have several questions:

1). Why does it produce different results on different platforms? I'll paste the screen-shots later.

2). I'm using a fail() method to check if the "file.read()" failed. Is this correct? I use fail() method because this web page says this:

The function returns true if either the failbit or the badbit is set. At least one of these flags is set when some error other than reaching the End-Of-File occurs during an input operation.

But later I read this page about istream::read() here. It says the eofbit and failbit would always be set at the same time.. Does this mean that a normal EOF situation would also result in that fail() returns true? This seems to conflict with "other than reaching the End-Of-File occurs"..

Could anyone help me clarify how I am supposed to use these methods? Should I use bad() instead?

My program

#include <iostream>
#include <fstream>
using namespace std;

#ifdef WIN32
char * path="C:\\Workspace\\test_file.txt";
#else
char * path="/home/robin/Desktop/temp/test_file.txt";
#endif

int main(int argc, char * argv[])
{
    ifstream file;

    file.open(path);
    if (file.fail())
    {
        cout << "File open failed!" << endl;
        return -1;  // If the file open fails, quit!
    }

    // Calculate the total length of the file so I can allocate a buffer
    file.seekg(0, std::ios::end);
    size_t fileLen = file.tellg();
    cout << "File length: " << fileLen << endl;
    file.seekg(0, std::ios::beg);

    // Now allocate the buffer
    char * fileBuf = new (std::nothrow) char[fileLen+1];
    if (NULL == fileBuf)
        return -1;
    ::memset((void *)fileBuf, 0, fileLen+1);    // Zero the buffer

    // Read the file into the buffer
    file.read(fileBuf, fileLen);
    cout << "eof: " << file.eof() << endl
         << "fail: " << file.fail() << endl
         << "bad: " << file.bad() << endl;
    if (file.fail())
    {
        cout << "File read failed!" << endl;
        delete [] fileBuf;
        return -1;
    }

    // Close the file
    file.close();

    // Release the buffer
    delete [] fileBuf;

    return 0;
}

The test_file.txt content(shown with "vim -b". It's a very simple file):

Result on Windows(Visual Studio 2008 SP1):

Result on Linux(gcc 4.1.2):

解决方案

Does this mean that a normal EOF situation would also result in that fail() returns true? This seems to conflict with "other than reaching the End-Of-File occurs".

I recommend using a reference that isn't full of mistakes.

http://en.cppreference.com/w/cpp/io/basic_ios/fail says:

Returns true if an error has occurred on the associated stream. Specifically, returns true if badbit or failbit is set in rdstate().

And the C++ standard says:

Returns: true if failbit or badbit is set in rdstate().

There's no "other than end-of-file" thing. An operation that tries to read past the end of the file, will cause failbit to set as well. The eofbit only serves to distinguish that specific failure reason from others (and that is not as useful as one might think at first).


I'm using a fail() method to check if the "file.read()" failed. Is this correct?

You should simply test with conversion to bool.

if(file) { // file is not in an error state

It's synonymous with !fail(), but it's more usable, because you can use it to test directly the result of a read operation without extra parenthesis (things like !(stream >> x).fail() get awkward):

if(file.read(fileBuf, fileLen)) { // read succeeded

You will notice that all read operations on streams return the stream itself, which is what allows you to do this.


Why does it produce different results on different platforms?

The difference you're seeing between Windows and Linux is because the file is open in text mode: newline characters will be converted silently by the implementation. This means that the combination "\r\n" (used in Windows for newlines) will be converted to a single '\n' character in Windows, making the file have only 8 characters. Note how vim shows a ^M at the end of the first line: that's the '\r' part. In Linux a newline is just '\n'.

You should open the file in binary mode if you want to preserve the original as is:

file.open(path, std::ios_base::in | std::ios_base::binary);

这篇关于为什么我的程序在Windows和Linux上产生不同的结果,有关ifstream的文件读取?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
相关文章
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆