C++ Cross Platform Compatible Binary File Open Read Problem

MatrixNAN · 09-17-2009, 12:09 AM

Hey Everyone,

I am stuck on this problem, and I don't know the right course of action to take. All of the code runs perfectly in Visual Studios 2008 C++ Express. All of the code except the binary load file works fine in Linux compiled in Eclipse for a C/C++ project. I am coding in OpenGL with SDL, but I don't think that is important for the following code. No error messages and no warnings for the entire project.

The uncompressed TGA file opens in Windows compile but not in Linux compile. What do I need to do in order to make my code compatible with Linux so that it will open binary files, and also be compatible still with Windows? I would like to maintain the OOP architecture of this program if possible with C++ for the code for opening the file. If this is not possible please let me know. Below is a bit of code where the problem is occurring.

Code:

bool Texture::loadTGA(string filename)
{
	ifstream file;
	cout << "Load TGA \n";
	cout << "File name = " << filename.data() << "\n"; 
	TGA_Header TGAheader;

//	ifstream file(filename.data(), std::ios_base::binary);
	file.open(filename.data(), std::ios_base::binary);

	cout << file << "\n";
	if( !file.is_open() )
	{
		cout << "File not open \n";
		return false;
	}

The if statement is proving to be true when I run the program and get the output. The filename.data() is working fine. I get the location of the file being passed in as "Textures/flame.tga" I have also tried reformatting the input to be "./Textures/flame.tga". The file is an uncompressed TGA and it runs and works in windows. When I cout file I get 0. When I check it in debug mode in Eclipse I get 0 with nothing more in regards to the file variable.

Cheers And Thanks In Advanced,
Nate Nesler

lutusp · 09-17-2009, 12:55 AM

Quote:

Originally Posted by MatrixNAN

Hey Everyone,

I am stuck on this problem, and I don't know the right course of action to take. All of the code runs perfectly in Visual Studios 2008 C++ Express. All of the code except the binary load file works fine in Linux compiled in Eclipse for a C/C++ project. I am coding in OpenGL with SDL, but I don't think that is important for the following code. No error messages and no warnings for the entire project.

The uncompressed TGA file opens in Windows compile but not in Linux compile. What do I need to do in order to make my code compatible with Linux so that it will open binary files, and also be compatible still with Windows? I would like to maintain the OOP architecture of this program if possible with C++ for the code for opening the file. If this is not possible please let me know. Below is a bit of code where the problem is occurring.

Code:

bool Texture::loadTGA(string filename)
{
	ifstream file;
	cout << "Load TGA \n";
	cout << "File name = " << filename.data() << "\n"; 
	TGA_Header TGAheader;

//	ifstream file(filename.data(), std::ios_base::binary);
	file.open(filename.data(), std::ios_base::binary);

	cout << file << "\n";
	if( !file.is_open() )
	{
		cout << "File not open \n";
		return false;
	}

The if statement is proving to be true when I run the program and get the output. The filename.data() is working fine. I get the location of the file being passed in as "Textures/flame.tga" I have also tried reformatting the input to be "./Textures/flame.tga". The file is an uncompressed TGA and it runs and works in windows. When I cout file I get 0. When I check it in debug mode in Eclipse I get 0 with nothing more in regards to the file variable.

Cheers And Thanks In Advanced,
Nate Nesler

You aren't being clear. You say "The if statement is proving to be true" but you don't say whether you mean the file is open or closed. After all, the test is:

Code:

if( !file.is_open() )

and !true = false, but you don't say which you mean.

Remember that you can safely use the std::ios_base::binary specifier on both Windows and Linux, because it has an effect on Windows but it is ignored on Linux (because everything is binary, there is no "text mode").

The choice to change the path to "./Textures/flame.tga" is a problem because it refers to the current directory, and you may not have established which directory you are in. I would find out which directory the program is running in and make sure it's the same in Windows and Linux, to eliminate a source of confusion.

One more thing I just noticed. The code sample is very short, and you don't say which "string" class is in use for the file name. But making some default assumptions, "string" is part of one era of C++ programming and "file.open()" belongs to another -- it require the use of the stringname.c_str() workaround, as demonstrated by this declaration for file.open():

Code:

void open ( const char * filename, ios_base::openmode mode = ios_base::in );

So either I am missing something basic or your "file.open(string.data() ..." is an obvious syntax error. It should be:

Code:

file.open(filename.c_str(), std::ios_base::binary);

Uncorrected, this error will cause all sorts of problems and it should be corrected everywhere in your program that requires an old-style, null-terminated C string.

tuxdev · 09-17-2009, 01:25 AM

Why are you not using SDL_Image?

MatrixNAN · 09-17-2009, 02:30 AM

Hey Guys,

Holycow I feel stupid. lol Oh my gosh it was the path. lutusp your comment got me thinking so I checked the path for where the application was executing from after it was compiled which is put into a debug folder in Eclispe which is a different location than VC++. I was thinking it would execute from the src folder but it does not so the directory I was passing it was wrong. I will have to set it up to for the ./src/Textures/flare01.tga etc. The sad part of this is that I rarely ever post questions on a forum about code, and I finally gave in after pulling my hair out over this error for some days now in my spare time.

Sorry to waste your guys time on such a stupid mistake on my part but your comments did solve the problem. Thank so much, who knows how many other days I would have been going crazy over such a simple mistake. filename.data() is not a syntax error it works in both Windows and Linux. I don't have a Mac OS X to test the code on it, but it should work on a Mac also. I apologize about the lack of clarity for the if statement. I meant that the file.is_open = false and the ! made the overall statement true which made the if statement execute. I was referring to the overall result of the test condition on that if statement. I will be more clear in the future. I think next time I will also include the out put during runtime to help with the clarity of what is going on.

tuxdev Is there some performance gain by using SDL_Image? The file path problem took care of other programs like the OBJ loader and the FBX Loader. So I was trying to kill several birds with one stone. I was doing the particle engine as a first test base for the cross platform compatibility. I plan to add a node based interface with property sheets for the particle effects and AI system. I plan on redoing a lot of this project to make it look much better particularly for the UI elements.

Running In Windows:

Running in Linux:

Cheers And Thanks Again Guys,
Nate Nesler

tuxdev · 09-17-2009, 10:00 AM

Using SDL_Image isn't about performance, it's about having a ton more flexibility in on-disk formats. If you're that concerned about the performance of loading assets, you're doing premature optimizations. The actual performance in-game is *far* more important.

Also, you might consider using PhysFS, a nice stacking virtual file system with support for lots of different archive formats.

Nice fire, btw

lutusp · 09-17-2009, 11:42 AM

Quote:

Originally Posted by MatrixNAN

... filename.data() is not a syntax error it works in both Windows and Linux. ...

And people get away with speeding, but this doesn't make it legal. It's a programming error, and it will work until it doesn't, then you will wonder what went wrong with your bug-free program.

The specification for ifstream.open() requires that the file path be provided as a null-terminated string --

Code:

void open ( const char * filename, ios_base::openmode mode = ios_base::in );

-- the fact that the compiler doesn't flag this error only tells us how loosely typed C++ is, not that it won't cause problems (or it means you have compiler warnings set too low).

I cannot overemphasize that this is a common mistake, and it will eventually cause problems. Some programmers complain about how strict some languages are about type compliance -- that is, when they aren't complaining about mysterious bugs in their programs.

MatrixNAN · 09-18-2009, 02:37 AM

Thanks tuxdev:

I have never used PhysFS thanks for the advice I am certainly going to check that out. Sounds like a really good idea and makes a lot of sense. After you mention of using the SDL_Image formats I looked up the book Focus on SDL. I am going to go through the whole book although its only about 3 chapters. I have been working off of just what was in the OpenGL books for the SDL as I prefer it over GLUT. Of course you would never make a game in GLUT.

I think for the next image format I implement it will be .dds DXT1-5. I am hand coding out the physics for now but later on I plan on implementing Bullet into the system. I have been looking over open steer also. I am hoping to have a nice demo that I can submit to the Blender Community to have an AI system, with a particle engine, GUI HUD system, to implement into the BGE. They already use SDL, C/C++, OpenGL, and Bullet.

Right now the fire is running at 6,500-7,500 fps with just display lists. I don't have it threaded or any of the other optimization methods which it could really benefit from. So I suspect the frame rate will go way up. I saw the threads in the SDL so I think I might give them a whirl later. The new OpenGL 3.2 spec looks really nice, and I think it will solve a lot of the headaches with SLI with OpenGL. Too bad it only is going to go back 1-2 years for software drivers.

If you think of anything else I would be interested in hearing it.

lutusp:

I changed the code to reflect your suggestion with the filename.c_str(). Honestly I have only been using Eclipse for a week and Visual C++ before that on Windows and before that Borland C++ Builder. So I wouldn't be surprised if the warnings were low in Eclipse by default. I will try and hunt around and see if I can turn them up higher.

This is the first time I have tried to get a C++ program to be cross platform compatible. I have only messed with C in Linux and Python in Linux before now. I think I will look over the file specs a bit more after your suggestions to make sure I don't have any other potential problems lying in wait. Thanks for setting me straight.

You Guys Have Been A Big Help More Than I Could Bargain For,
Nate Nesler