By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,837 Members | 1,206 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,837 IT Pros & Developers. It's quick & easy.

Checking for valid data in file

P: n/a
I have a file that looks like this:

25.000000 55.000000
23.000000 51.000000
5 8
8700 6000
<and then, at byte 128, starts binary stuff>

What's the proper way to make sure that I'm reading in valid data?
Should I check after each cin that the input stream isn't eof?

Also, if the user gives the program an argument on the command-line that
represents a file name, how do I check (without resorting to
platform-specific languages) that the file exists and is readable? Do I
just try reading it?

Thanks,
Joe
Mar 17 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
Joe Van Dyk wrote:
I have a file that looks like this:

25.000000 55.000000
23.000000 51.000000
5 8
8700 6000
<and then, at byte 128, starts binary stuff>

What's the proper way to make sure that I'm reading in valid data?
What's "valid data"?
Should I check after each cin that the input stream isn't eof?
Probably. What does this have to do with the "binary stuff" that "starts"
at "byte 128"?
Also, if the user gives the program an argument on the command-line that
represents a file name, how do I check (without resorting to
platform-specific languages) that the file exists and is readable? Do I
just try reading it?


Yes, there is no other definition of "readable" in C++. Of course, it is
often enough to successfully open it for reading (without actually reading
it), but you get the idea.

V
--
Please remove capital As from my address when replying by mail
Mar 17 '06 #2

P: n/a
Joe Van Dyk wrote:
I have a file that looks like this:

25.000000 55.000000
23.000000 51.000000
5 8
8700 6000
<and then, at byte 128, starts binary stuff>

What's the proper way to make sure that I'm reading in valid data?
Should I check after each cin that the input stream isn't eof?

Also, if the user gives the program an argument on the command-line that
represents a file name, how do I check (without resorting to
platform-specific languages) that the file exists and is readable? Do I
just try reading it?

Thanks,
Joe


Also, the binary data is a series of structs that have a short, two
unsigned characters, and a long. What's the idiomatic C++ way of
reading that data?

Mar 17 '06 #3

P: n/a
Joe Van Dyk wrote:

Also, the binary data is a series of structs that have a short, two
You mean, it's some binary representation of a series of instances of
structs with a short...
unsigned characters, and a long. What's the idiomatic C++ way of
reading that data?


If it's text, create a stream operator for it:

struct mystruct{};

std::istream& operator>>(std::istream& is, mystruct& s) {
// is >> stuff;
return is;
}

If it's binary, then who knows.

Ben Pope
--
I'm not just a number. To many, I'm known as a string...
Mar 17 '06 #4

P: n/a
Victor Bazarov wrote:
Joe Van Dyk wrote:
I have a file that looks like this:

25.000000 55.000000
23.000000 51.000000
5 8
8700 6000
<and then, at byte 128, starts binary stuff>

What's the proper way to make sure that I'm reading in valid data?

What's "valid data"?


"valid data" would be that the file contains 2 doubles followed by 2
doubles followed by 2 unsigned ints followed by 2 unsigned ints.
Should I check after each cin that the input stream isn't eof?

Probably. What does this have to do with the "binary stuff" that "starts"
at "byte 128"?


Starting at byte 128 in the file, there's a bunch of the following structs:

typedef struct
{
short vtxElev; /* vertex elevation */
u_char vtxZone; /* terrain fearture type */
u_char vtxMono; /* monochrome brightness value */
ulong vtxVrgb; /* rgb color components of vertex */

} CELL_TYPE;

I need to get the rgb color information out of the vtxVrgb elements.
The structs are stored in network-byte order (if it matters).
Also, if the user gives the program an argument on the command-line
that represents a file name, how do I check (without resorting to
platform-specific languages) that the file exists and is readable? Do
I just try reading it?

Yes, there is no other definition of "readable" in C++. Of course, it is
often enough to successfully open it for reading (without actually reading
it), but you get the idea.


Thanks,
Joe
Mar 17 '06 #5

P: n/a
Joe Van Dyk wrote:
Victor Bazarov wrote:
Joe Van Dyk wrote:
I have a file that looks like this:

25.000000 55.000000
23.000000 51.000000
5 8
8700 6000
<and then, at byte 128, starts binary stuff>

What's the proper way to make sure that I'm reading in valid data?

What's "valid data"?


"valid data" would be that the file contains 2 doubles followed by 2
doubles followed by 2 unsigned ints followed by 2 unsigned ints.


But it doesn't. You just said that somewhere "starts binary stuff".
If the file doesn't end there, it's not "valid data". Your file either
contains formatted stuff or it contains unformatted (binary) stuff. If
it has both, it's not normal.

You could of course read out your 128 (or 127, or whatever) bytes into
a string, and then use that string to initialise an istringstream and
then read those doubles and unsigneds out of the istringstream.
Should I check after each cin that the input stream isn't eof?

Probably. What does this have to do with the "binary stuff" that
"starts" at "byte 128"?


Starting at byte 128 in the file, there's a bunch of the following
structs:
typedef struct
{
short vtxElev; /* vertex elevation */
u_char vtxZone; /* terrain fearture type */
u_char vtxMono; /* monochrome brightness value */
ulong vtxVrgb; /* rgb color components of vertex */

} CELL_TYPE;

I need to get the rgb color information out of the vtxVrgb elements.
The structs are stored in network-byte order (if it matters).


I don't see the problem. You know where in the file your binary data
start, you know what it looks like, so just read it using 'read'.

V
--
Please remove capital As from my address when replying by mail
Mar 17 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.