How does one read in 32 bits at a time from a binary file?

[KantKwitDansin1]

I have a file "a.dat" containing 10^4 32 bit binary numbers. I need to
read in these numbers and deterimine if they are prime. The primality
part I will have to figure out later, but I was wondering if there is
anyone out there that can help me in reading in the binary numbers.
Basically, read in 32 bits and thats
the first number, read in another 32 bits and thats the 2nd
number, etc. Is is something like this?
fread(char, sizeofchar, numberofelements, filepointer)

 

[jdog1016]

Well, 32 bits is 4 bytes, which is just an int (on i386, usually). So:

fstream file;
int n;
file_position = 0;
file.open("filename", ios::in | ios::binary);

file.seekg(file_position, ios::beg);
file.read(n, 4);

and then you just increase file_position by 4 each time you run those
last two lines. Hope that helps.

 

[Jacek Dziedzic]

Well, 32 bits is 4 bytes, which is just an int (on i386, usually). So:

Would that not differ across compilers, even on i386?
I can imagine sizeof(int) == 2 and sizeof(long int) ==4.

I think the OP might want to either make sure that sizeof(int)
is indeed 4 or read in char[4] chunks, expecting a char to be
8 bits wide.

fstream file;
int n;
file_position = 0;
file.open("filename", ios::in | ios::binary);

file.seekg(file_position, ios::beg);
file.read(n, 4);

and then you just increase file_position by 4 each time you run those
last two lines. Hope that helps.

As a side note -- is it necessary to seek to the beginning of
a filestream after opening it? I personally never do that.

- J.

 

[jdog1016]

I think the OP might want to either make sure that sizeof(int)

is indeed 4 or read in char[4] chunks, expecting a char to be
8 bits wide.

Absolutely. To do it properly, one really shouldn't hardcode it at
all, but just simply read sizeof(int) to an int. That way it will be
portable not only across compilers, but across different architectures
as well.

As a side note -- is it necessary to seek to the beginning of
a filestream after opening it? I personally never do that.

No, it definitely isn't, but if you're going to be reading in say, all
of a file, you'll want to do a seekg() each time you read (perhaps in a
for loop) to move your read head.

 

[Karl Heinz Buchegger]

I think the OP might want to either make sure that sizeof(int)
is indeed 4 or read in char[4] chunks, expecting a char to be
8 bits wide.

Absolutely. To do it properly, one really shouldn't hardcode it at
all, but just simply read sizeof(int) to an int. That way it will be
portable not only across compilers, but across different architectures
as well.

???
I am not sure if I understand correctly what your wrote.
Portability with reading on a binary level is a hard thing.
That is: You write the file on one platform. Transport it to
another platform and read it there. Not only can sizeof(int)
differ on both platforms, but also can byte ordering (or
in case of floating point values the whole bit layout).
So binary portabitility is also easiliy achievable if those
2 programs which read and write the data, or compiled by the
same compiler, same compiler version on the same platform.

No, it definitely isn't, but if you're going to be reading in say, all
of a file, you'll want to do a seekg() each time you read (perhaps in a
for loop) to move your read head.

Why? Just read on. The 'read head' will move just by 'read'-ing
the file.

 

[jdog1016]

I was just saying that you would want to use 'sizeof(int)' rather than
simply '4.' That's all.

As for the read head thing, I'm sorry, I completely mixed myself up.
You're right

 

[Karl Heinz Buchegger]

I was just saying that you would want to use 'sizeof(int)' rather than
simply '4.' That's all.

Then I read more into your post then you intended.
Apologies.
It sounded to me as: just use sizeof(int) instead of 4 and all
your portability problems are solved.

As for the read head thing, I'm sorry, I completely mixed myself up.
You're right

No problem. It happens to all of us

 

[Ron House]

I am not sure if I understand correctly what your wrote.
Portability with reading on a binary level is a hard thing.
That is: You write the file on one platform. Transport it to
another platform and read it there.

That's right. I have more or less concluded that binary files are a dead
loss for average use. I inherited a program with a binary file format
once, and had to put in some additions. Result: entirely new struct
definitions, then converter programs, etc. Then I put it on Linux as
well as DOS. Big trouble, as padding was different on the same
processor. But after I converted to a text format, all these troubles
went away (provided I wrote once-only bullet-proof cr/lf recognising code).

I assigned a version of the file a version number. Then, when new
versions added fields to the data, I upped the number. Output always
sent out the latest version, but input code had this form:

read original fields
if (version > 1) { read some more fields } else set sensible defaults
if (version > 2) { read yet more... } else set defaults...

I am up to about version 20 and have an app that is almost
unrecogniseable from the original, but it still reads and correctly
loads the very first file format (not counting the binary ones, that is!).

I had to delete some fields in one version. Even that can be sensibly
handled in an obvious way.