View Full Version : in_stream.open("infile.dat"); // Under OSX?

Oct 26, 2004, 03:38 PM
So I'm in a beginner C++ class here at Whitworth college, and of course all the dev is on Windows computers. I've realized though that it is just about all cross platform code, and so have been using my powerbook and Xcode to do a lot of my homework. Until now...

we are bring in file information from a .dat files, which doesn't work for me in OSX. I few questions...

1. Is there a program that will save a .dat file? txt isn't an equivalent I found out.

Does there exist very SIMPLE and beginner level set of code that I can use in place of - in_stream.open("infile.dat");
where "in_stream" is the stream variable name?

Basically I now can't test my code on my computer, because I can't get .dat files, or any files, into the program. If the answer is elongated and involves changing too much of my code than it becomes pointless, because the point is to test my code, not to port it.

But, for the sake of learning, I'd enjoy knowing :)

Thanks guys!

I don't plan on asking many programming questions, but perhaps someone could suggest a Mac friendly, newbie friendly, C++ coding environment for cross platform questions? I know that Macrumors isn't exactly website for dev, there for neither are the forums to a degree...

Oct 26, 2004, 07:53 PM
i don't think their should be any type of problem. If you are reading a file, whatever the extension is, what are you doing with the data in it? are you reading the data for a specific reason. when you import data to a code, one problem that can arise is if the file is in binary. Then you'd have to add a couple of things to read the file.

Perhaps you can be a little more specific with your problem.

Hope this can help any.

Oct 27, 2004, 10:04 AM
Well, you may just not be opening the file correctly, if it is in binary mode and such, you have to treat things differently.
Perhaps these can help you a bit, I would probably also check the permissions on the file to see if you are able read/write the file in question.

Oct 27, 2004, 11:08 AM
Which classes are you trying to use to open the file? Perhaps you could post your code?

Oct 27, 2004, 01:57 PM
I would have posted my code before, except that I hadn't been to the lab to debug it, so there were many many errors none of which are related to the issue.

The following code compiles fine under visual studio on a windows machine:

#include <fstream> //includes the library for ifstream and ofstream
#include <iostream>
#include <cstdlib>

using namespace std;

int main()
int s, l, next; // declares variables
ifstream in_stream; // declares a stream

in_stream.open("infile.dat"); // matches a stream with a file. Opens the file
if (in_stream.fail()) // fail safe if statement that will exit the program upon the failing of opening the file
cout << "Input file opening failed.\n";

in_stream >> next;
s = next;
l = next;
if( s < next)
s = next;
if( l > next)
l = next;
} while (in_stream >> next); // reads information from the file and assigns it to variables

in_stream.close(); // closes the file

cout << "The largest number in the file is " << l << ", and the smallest is " << s << "\n\n";
cout << "G'day!\n";

return 0;

Thanks for looking guys,
Tyler Z.

Oct 27, 2004, 04:20 PM
if( s < next)
s = next;
if( l > next)
l = next
Are you sure this is working? I copied and pasted the code using xcode. It compiled. But, the infile.dat I'm using has one line with all the numbers separated by whitespace. Is this how the file is going to be? Another when executed, it gave me the answers backwards. Meaning smallest is the highest and highest is the smallest.
this is the file I created. just one line. Maybe since it doesn't have an end of file their could be a problem. but anyways, the program gave me smallest=8787 and highest=0. Check that if again.
2 34 8787 10 0 234 93 5

I guess the if should go the other way around.if(next<s)

this gives me, largest=8787 and smallest=0

at least for this case.
2 34
10 0 234

Should also work.

Nov 2, 2004, 04:38 PM
Also, you're .dat file MUST be located in the build folder of your project. I make this mistake all the time.

May 28, 2005, 09:34 AM
I'm doing my own thing and the ifstream fails.
ifstream fooinput;
bool failed;
failed = fooinput.fail();
cout << failed << endl;
That seems to fail every time. The file is a text file. I tried it with the file in the project directory, with normal path and absolute path, checked permissions, blah blah. I'm running Tiger. Could there be an issue?

May 28, 2005, 07:48 PM
Also consider that if you do any writing to the a .dat file in Windows, you won't be able to read it in properly without converting the numbers from little-endian to big-endian. If they're just stored as text though (as opposed to actual numbers), or you're not doing any writing, don't worry about it.

May 30, 2005, 05:18 PM
I ran this program:
#include <iostream>
#include <fstream>

using namespace std;

int main() {
int i(0);
ifstream in_file;
static const int BUF_SIZE( 80 );
char buf[BUF_SIZE];


cerr << "DEBUG: in_file.bad() = " << (in_file.bad() ? "true" : "false") << std::endl
<< "DEBUG: in_file.fail() = " << (in_file.bad() ? "true" : "false") << std::endl;

while(true) {
in_file.getline( buf, BUF_SIZE );
if(in_file.eof() == true) break;
else if(*buf != char(0)) cout << "Line " << (++i) << ": " << buf << std::endl;

cout << "End of file reached after " << i << " non-empty lines." << std::endl;
return 0;
with this file, called input.dat:
This line has text. The next line has numbers....
10 2348 3.14159 203.5
This is the last line. I will terminate it with an EOL to be safe...

This was the outcome:
vanguard:~/src/ifstream rinseout$ ./test
DEBUG: in_file.bad() = false
DEBUG: in_file.fail() = false
Line 1: This line has text. The next line has numbers....
Line 2: 10 2348 3.14159 203.5
Line 3: This is the last line. I will terminate it with an EOL to be safe...
End of file reached after 3 non-empty lines.
vanguard:~/src/ifstream rinseout$
Hope this helps... perhaps it's an issue with your delimiter. The EOL character(s) is different between DOS and OS X (or at least it used to be?). Since your files are text you can disregard the worrying about endianness.