Sign in to follow this  

Reading in binary .dat file gives garbage (C++)

This topic is 3727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, This is related to an assignment I've been set but I'm not asking for help on how to do it, it's just I'm getting some truly baffling issues when I try to make my code work (I wrote it myself, like I say I'm not asking for you to code it all up for me, don't know if that gets round the rules or not). Essentially, I've been given this binary DAT file with values representing an image. There's 512 lines with 512 values on each and each value falls between 0 and 255 so there's 256 possibilities. I've got to determine how many instances there are of each value e.g. there might be 6000 which equal 138. Problem is I can't get the .dat file to read properly. I'm using the following code:
void fileParser::openFile(void)
{
	this->fileHandle.open("IMAGE.DAT",std::ios::in | std::ios::binary);

	if(!fileHandle)
	{
		std::cout<<"Error opening file."<<std::endl;
	}else{
		this->fileIsOpen = true;
		this->readFile();
	}
}


void fileParser::readFile(void)
{

	// We should have 512*512 iterations i.e. 262144
	char buffer = ' ';
	
	std::cout<<"Got into fileParser::readFile();"<<std::endl;

	if(this->fileIsOpen == true)
	{
		std::cout<<"File is open at this point."<<std::endl;
		system("pause");
	}else{
		std::cout<<"fileParser::readFile(): FAIL: file is not open at this point"<<std::endl;
	}

	int i = 0;
	this->fileHandle >> buffer;

	while(!this->fileHandle.eof())
	{
		this->fileHandle >> buffer;
		std::cout<<"Currently got "<<buffer<<" in the buffer."<<std::endl;
	}
	
	this->fileHandle.close();
	// Currently this routine takes ~6 minutes and 30 seconds :S
	

}


fileHandle and these functions are members of a class. The problem I'm having is that when I read in the file and display each character on screen (like I say it's taking ~6 minutes right now [grin], it's purely for testing/debug purposes right now) what I see on screen is usually different to the same point in the file. Here's a sample run for you: The results I get when I set up a for loop to grab the first 10 items in the DAT file The actual file contents at the same point I've tried moving my code around, making sure everything's initialised etc., no dice. What's going on here, are they supposed to be the same or what? I haven't done this sort of stuff in ages and the lecturer barely knows it either, hell he needed help getting MSVS to run Hello World and we spent a whole week doing virtually nothing. If anyone here can at least tell me what the problem is even if you don't offer a 100% solution, it's assignment work so I don't expect a worked exemplar from you or anything because I know that's frowned upon around here. Cheers in advance, ukd.

Share this post


Link to post
Share on other sites
There's a non-zero chance that your program is actually working correctly. The console window tends to display data differently than opening binary data in a text editor. I would open your data file in a hex editor and instead of outputting the char to the console, output the numeric value of the char (or output both). Compare the number to the values in the hex editor.

Share this post


Link to post
Share on other sites
1) The main reason it's taking 6 minutes right now, almost certainly, is (a) you're reading a tiny bit at a time and (b) for *every* read, you output a debug message, which is slow. These things add up.

2) When you use operator>> to read into a char variable, it will skip whitespace. The file reading operations don't care about the mode the file was opened in. Use .get() to read a single character at a time, or .read() to fill a buffer of chars.

3) Don't make your own class to wrap file handles unless you really, really know what you're doing. Stream objects can't be copied, and there is actually quite little useful functionality you can add with your own layer of wrapping (except possibly for creating something copyable, with clever use of boost::shared_ptr for example). If you think you are making things "more OO" this way then you have sadly missed the point in quite a few ways.

4) If you use a std::istream specifically, you won't need to specify std::ios::in for the file mode. Also, stream objects don't normally need to be .close()d explicitly (although your class design probably is introducing this requirement).

5) What SiCrane said. :)

Share this post


Link to post
Share on other sites

This topic is 3727 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this