Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

Earendil

macrumors 68000
Original poster
Oct 27, 2003
1,598
83
Washington
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!
Tyler

ps
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...
 

iBert

macrumors regular
Jul 14, 2004
148
0
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.
 

Earendil

macrumors 68000
Original poster
Oct 27, 2003
1,598
83
Washington
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";
exit(1);
}

in_stream >> next;
s = next;
l = next;
do
{
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.
 

iBert

macrumors regular
Jul 14, 2004
148
0
Code:
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.
Code:
2 34 8787 10 0 234 93 5

I guess the if should go the other way around.
Code:
if(next<s)
 s=next;
if(next>l)
 l=next;
this gives me, largest=8787 and smallest=0

at least for this case.
EDIT:
Code:
2 34
8787
10 0 234
93
5

Should also work.
 

mmmdreg

macrumors 65816
Apr 14, 2002
1,393
0
Sydney, Australia
I'm doing my own thing and the ifstream fails.
//
ifstream fooinput;
fooinput.open("path.to.foo.file");
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?
 

GeeYouEye

macrumors 68000
Dec 9, 2001
1,669
10
State of Denial
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.
 

rinseout

macrumors regular
Jan 20, 2004
160
0
There is nothing wrong with Tiger.

I ran this program:
Code:
#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];

  in_file.open("input.dat");

  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;
  in_file.close();
  return 0;
}
with this file, called input.dat:
Code:
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:
Code:
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.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.