I have the task of creating a load save system for an application written in C. Documentation indicates that fread and fwrite can be used to read/write entire structures to disc, but I want something that will work compatibly across any ANSI C implementation and I don't think this will. If I load and save the structure one field at a time, will this portable? If not, what's the best method? I'm trying to avoid the full XML route.
Portable file saving in C
Miscellaneous Forums/General Discussion/Portable file saving in C I imagine creating your own bytestream would be the best solution to this problem. That way you know how its saved and you can easily write loaders for both endian systems and whatnot.
I tried to avoid the full XML route and regretted it later. It only wasted about three days because I regretted it a lot sooner than I could have done. Still it's three days I could have used for other things.
Thanks both for the ideas. After some research on the net, I'm coming to the same conclusion as you, Gabriel.
The problem with a straight byte stream is that you have to reassemble it into C built-in types, which involves compiler/machine dependant assumptions.
The down-side with XML is the problem of maintaining the exact value of floats.
The problem with a straight byte stream is that you have to reassemble it into C built-in types, which involves compiler/machine dependant assumptions.
The down-side with XML is the problem of maintaining the exact value of floats.
Thanks mate... that one may be of some use for me in the future. At the mo I'm developing in C rather than ++ and (I neglected to mention) the software has to be written to a set of critical safety standards, so any 3rd party stuff would need
a fair bit of work to bring up to standard, and I would need the source code.
a fair bit of work to bring up to standard, and I would need the source code.
Arn't fread and fwrite ANSI C standard library functions? Wouldn't that mean they can be used on all platforms with a C compiler?
Zenith: I'm fairly sure you're right, but I have a niggling doubt regarding certain compiler libraries not taking endianness into account. best to roll your own.
Well I have to admit that I haven't tried using fread and fwrite across different machines, but what I'm reading on the net leads me to believe it won't work. I don't actually have access to a PPC Mac or whatever to try it.
My guess is that XML is the safe way to go.
You do need to take some care about floating point values converted to text and later read back to their native binary format. This will work exactly if you use enough digits, nine for single precision and seventeen for double.
You do need to take some care about floating point values converted to text and later read back to their native binary format. This will work exactly if you use enough digits, nine for single precision and seventeen for double.
fread and fwrite IIRC are in stdio.h they should be standard commands across any C version.
This is from the C-FAQ, which I take to be the gospel...
http://c-faq.com/struct/io.html
According to that, writing structures in 1 operation is not portable. Writing field by field is the way forward if done in a 'portable, perhaps human readable way'. It's a bit vague, but leads me to think straight fwrite, field by field is not portable.
http://c-faq.com/struct/io.html
According to that, writing structures in 1 operation is not portable. Writing field by field is the way forward if done in a 'portable, perhaps human readable way'. It's a bit vague, but leads me to think straight fwrite, field by field is not portable.
XML is a bad way of storing data if you're only concerned with portability. It's too bloaty really. ISTR endianness being an easyish thing to deal with in C (from the old Amiga days).
**EDIT** BTW, endianness is something that is dealt with in most networking code, because network byte order is the opposite of x86 byte order.
**EDIT** BTW, endianness is something that is dealt with in most networking code, because network byte order is the opposite of x86 byte order.
I am only concerned with portability. Think I may just account for the endian issue and worry about anything else if it arises. Then again, I may end up regretting it and wishing I had taken Gabriel's advice. The fact that I can't be bothered to (re)write an XML parser is the deciding factor.
I still think that saving to some kind of text file is the way to go, although it doesn't have to be XML in all its glory.
It sure makes debugging easier when you can simply look at the files in a text editor.
It sure makes debugging easier when you can simply look at the files in a text editor.