Weird technical issue

[sargon94]

So I have this code, it converts (supposedly) a million chars into shorts with file streaming, but it always crashes after 77 thousand (roughly)
What's wrong with it?

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

int main()
{
    signed char lol;
    ofstream out;
    ifstream in;
    //signed char test[1000000];
    in.open ("file.txt");
    out.open ("file2.txt");
    for (int i=0; i<1000000; i++)
    {
        in>>lol;
        //cout<<lol<<" "<<(int)lol<<endl;
        out<<(short)lol<<endl;
        if (i>50000)
        {
            in.clear();
            out.flush();
        }
    }
    return 0;
}

EDIT: fixed a typo

[SIK]

I think you should add a safety check in your for loop:

for (int i=0; i<1000000 && !in.eof(); i++)

It may be that your read from [file.txt] is failing. If that is the case, I find it strange that the failure is not consistent - ie too few chars in [file.txt] should usually cause a consistent failure at a particular value.

Also remove the [in.clear()] call.

[sargon94]

Thanks, I added the less than million thing after I removed the !in.eof(), it always crashes at the same point too, and I know there are many more chars than 77000, there really are a million of them in there. Can the ifstream buffer overload? and if so, is there a way to flush it?
EDIT: Do you know of a better (or different) way to convert chars into their ascii value? That would be just fine as well for a solution.

[sargon94]

So I've done more research and testing, the problem lies in the ifstream failing to read once it reaches a certain point, any idea what could cause this? (and how to fix it would be very nice as well)

[SIK]

There should be no need to manually flush the fstream object - this should be handle internally by the object itself automatically.

Can you comment out lines 18-22 and rerun - there should be no reason for this manual flush and also want to ensure that the clear call on the in object is removed.

Since this program crashes at exactly the same iteration each time on your system, will it be able to debug it around the crash point.

Basically add the following inside your for loop:

if (i == CRASH_POINT_ITER)
{
   cout << "Mush break here" << endl;
}

CRASH_POINT_ITER should be define to the value at which you program crashes. Then if possible with the ide you are using, place a break point on the cout statement and run in debug mode.

The debugger should break at this point where you can then manually step through the rest of the code and hopefully see the extact point where your program crashes.

You may also need to step into the actual fstream call to either read or write to file.

Let me know what you find.

[sargon94]

Ok, I did exactly that, so this is the code currently:

#include <iostream>
#include <fstream>
#include <windows.h>
using namespace std;

int main()
{
    signed char lol;
    ofstream out;
    ifstream in;
    //signed char test[1000000];
    in.open ("file.txt");
    out.open ("file2.txt");
    for (int i=0; i<1000000; i++)
    {
        if (i==77949)
        {
            cout<<"SHIT I BROKE IT\n";
        }
        in>>lol;
        if (in.fail())
        {
            cout<<"FAILED! ";

        }
        //cout<<lol<<" "<<(int)lol<<endl;
        cout<<lol<<" "
        <<(int)lol<<" ";
        cout<<i<<endl;
    }
    system ("pause");
    return 0;
}

The issue happens on line 20, (the input) because right after I get the crash point the 'if (fail)' line goes of (and keeps doing it for as long as the code runs, unless I add !in.eof in the condition, then it just ends the loop), this is seriously confusing. it seems like it keeps getting an input it doesn't like and quits the stream, what could cause this?

[SIK]

This is strange - can you post your input file somewhere - I'd like to test with it myself on my system.

[SIK]

Not that it should make any difference, but could you also tell me what ide and os you are using?

[sargon94]

Alright, here's the link :http://www.2shared.com/document/4PW9iiXb/file.html
I'm using Windows 7 Enterprise and the file creator was created with VS 2010 while the Converter program was created by Code::Blocks

[SIK]

I downloaded the file you posted and tested on my system. Strangely the program did not crash on my side, but did note some other things which lead me to analyse your file more closely and eventually saw that it contained non printable characters (which shouldn't be in text files) and some lines that did not end with both a line feed and cariage return.

I think this is causing an issue on your side when you open [file.txt] in text mode and proceed to process. The fstream object [in] may be forced into undefined behaviour when it encounters these unpritable chars or a combination of it and the line ends.

In particular, I found an unprintable character on line [77945] when viewing under TextPad. Visual Studio moaned about the unpritable characters and some line feeds 'missing'. Not sure that file will even be interperated the same across various applications for viewing this file in text mode as file is not a legal text file.

Would you like help with your file creator program - I think the real issue is in it.