Michael Calkins (Login MCalkins) C-Forum Posted May 2, 2011 3:33 AM
>I dont quite see what you did to make the struct normal (as you say) so it uses . instead of ->
sRec = new SalesRecord();
>I know you said file I/O is not your thing
File I/O in C++, because of the "streams". I can do file I/O in QBASIC well enough.
>They are allways 0 in the program
They are all 0 except the first one. The first input reads the whole thing, and there is nothing left for the others.
>This version has as you suggested, binary format for the file
Okay. I don't see the change. Again, this whole OOP concept of streams is strange to me.
>i managed to fix the records size problem i was having to.
It seems to be correctly figuring size of file in bytes / 20. (20 = 5 ints of 4 bytes each. Since they are all the same size, there is no padding.) However, the contents of the file are still ASCII decimal numbers, instead of raw binary data. So, the file varies in length, and it is a coincidence that it matches in this case.
What exactly is the file stream with the bit shift operator << doing? Is it converting the numbers to decimal strings and then concatenating them?
Is there some sort of separator that you can use that the file input will respect? I had tried comma and endl earlier without success.
Hopefully someone with C++ file I/O experience will come along and clear this up. The two solutions I'm thinking of probably wouldn't be ideal. One would be to revert to procedural file I/O, either through the C standard library, or through the operating system API. The other would be to manually convert your numbers to fixed length hex numbers for output and manually convert them back for input. I don't know if C/C++'s treatment of null as a terminator would cause problems if you tried working with raw binary numbers.
So far I've been trying to avoid reading about C++ file streams, partly because I actually don't care to learn C++, but I guess I'll try to read a little about it.