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

Problem with C-style binary I/O

P: n/a
I am running in debugging mode after a clean C++ compilation under .NET 2003. In a BIG loop (controlled many levels up in the call stack), I open a file with fopen using the "a" option. Then I write 23 doubles to it with fwrite, one call for each double. Then I close the file using fclose. After three times around the loop in the debugger, I stop the program (using "Stop debugging"). That is writing 552 bytes.

The resulting file's properties window says it is the file size is 555 bytes.

I read the file using another program (MATLAB). The first 37 doubles are exactly what they should be. The rest are seemingly random numbers with large (positive and negative) exponents. I have used this version of MATLAB to read binary data files a great many times without problems, so I don't think the problem is on that end.

I have gotten the exact same crazy behavior calling frwrite with a pointer to an array of doubles holding the 23 values and many various on that theme. I tried using (o)fstream instead of C-style calls initially but ran into a problem compiling the fstream header file (see my previous posting). I expect to be writing some very large data files and would really prefer to ues binary I/O as opposed to formated.
Has anyone else had similar problems? If so, how did you fix them or work around them?

Does the .NET 2003 development environment have a tool like the UNIX "od" which would let me inspect the binary file I create?

Thanks any advance for any assistance,

John
Nov 16 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
John R. Delaney wrote:
I am running in debugging mode after a clean C++ compilation under
.NET 2003. In a BIG loop (controlled many levels up in the call
stack), I open a file with fopen using the "a" option. Then I write
use "ab"
23 doubles to it with fwrite, one call for each double. Then I close
the file using fclose. After three times around the loop in the
debugger, I stop the program (using "Stop debugging"). That is
writing 552 bytes.

The resulting file's properties window says it is the file size is
555 bytes.
That's because you opened a file in "text mode" and then wrote binary data
to it. Opening the file in binary mode will behave as you expect. Unix
typically doesn't differentiate between "text" and "binary" mode for C
streams at all, so code that works on Unix may fail on Windows if it was
using the incorrect mode.

I read the file using another program (MATLAB). The first 37 doubles
are exactly what they should be. The rest are seemingly random
numbers with large (positive and negative) exponents. I have used
this version of MATLAB to read binary data files a great many times
without problems, so I don't think the problem is on that end.
Anywhere the byte 0x0a occurred, another byte of 0x0d was inserted after it.
You can imagine what a mess that makes of binary doubles.

I have gotten the exact same crazy behavior calling frwrite with a
pointer to an array of doubles holding the 23 values and many various
on that theme. I tried using (o)fstream instead of C-style calls
initially but ran into a problem compiling the fstream header file
(see my previous posting). I expect to be writing some very large
data files and would really prefer to ues binary I/O as opposed to
formated.
Has anyone else had similar problems? If so, how did you fix them or
work around them?
See above.

Does the .NET 2003 development environment have a tool like the UNIX
"od" which would let me inspect the binary file I create?
You can open a binary file in the Visual Studio IDE - just open it with the
regular File|Open|File... menu option, and click the drop-down button on the
"OK" button in the dialog, choose "Binary Editor" from the list that
appears.

Thanks any advance for any assistance,

John

Nov 16 '05 #2

P: n/a
Thank you, Carl Daniel. I had overlooked the 'b' option in fopen. Turns out I have to scroll down several pages in the online documentation to find it so I don;t feel quite as stupid as I might. But I do still feel stupid

And thank you for directing me to the binary editor. Its association with resource files in the documentation helped me overlook it. It is better than 'od' in that it does allow one to edit binary files but it does not seem to allow one to impose alternative interpreations on the binary data (bytes, chars, ints, doubles, etc.) Is there something I missed (again)

With graditude and respect

John Delane

----- Carl Daniel [VC++ MVP] wrote: ----

John R. Delaney wrote
I am running in debugging mode after a clean C++ compilation unde
.NET 2003. In a BIG loop (controlled many levels up in the cal
stack), I open a file with fopen using the "a" option. Then I writ
use "ab
23 doubles to it with fwrite, one call for each double. Then I clos
the file using fclose. After three times around the loop in th
debugger, I stop the program (using "Stop debugging"). That i
writing 552 bytes
The resulting file's properties window says it is the file size i

555 bytes


That's because you opened a file in "text mode" and then wrote binary dat
to it. Opening the file in binary mode will behave as you expect. Uni
typically doesn't differentiate between "text" and "binary" mode for
streams at all, so code that works on Unix may fail on Windows if it wa
using the incorrect mode
I read the file using another program (MATLAB). The first 37 double

are exactly what they should be. The rest are seemingly rando
numbers with large (positive and negative) exponents. I have use
this version of MATLAB to read binary data files a great many time
without problems, so I don't think the problem is on that end


Anywhere the byte 0x0a occurred, another byte of 0x0d was inserted after it
You can imagine what a mess that makes of binary doubles
I have gotten the exact same crazy behavior calling frwrite with

pointer to an array of doubles holding the 23 values and many variou
on that theme. I tried using (o)fstream instead of C-style call
initially but ran into a problem compiling the fstream header fil
(see my previous posting). I expect to be writing some very larg
data files and would really prefer to ues binary I/O as opposed t
formated
Has anyone else had similar problems? If so, how did you fix them o work around them


See above
Does the .NET 2003 development environment have a tool like the UNI

"od" which would let me inspect the binary file I create


You can open a binary file in the Visual Studio IDE - just open it with th
regular File|Open|File... menu option, and click the drop-down button on th
"OK" button in the dialog, choose "Binary Editor" from the list tha
appears
Thanks any advance for any assistance
John

Nov 16 '05 #3

P: n/a
John R Delaney wrote:
Thank you, Carl Daniel. I had overlooked the 'b' option in fopen.
Turns out I have to scroll down several pages in the online
documentation to find it so I don;t feel quite as stupid as I might.
But I do still feel stupid.

And thank you for directing me to the binary editor. Its association
with resource files in the documentation helped me overlook it. It is
better than 'od' in that it does allow one to edit binary files but
it does not seem to allow one to impose alternative interpreations on
the binary data (bytes, chars, ints, doubles, etc.) Is there
something I missed (again)?


I thought there was an option to display byte, shorts or ints (definitely
not floats or doubles), but I can't find it. I must be thinking of some
other program.

-cd
Nov 16 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.