tags:

views:

81

answers:

3

The idea is that an application may contain a struct of large arrays that are filled up via a slow external library. So, what if that could be easily stored to a file for fast reference, at least after it has been run once? If it's not possible to be done easily in a cross platform way, is it easy to be done locally 'after a first run'?

+3  A: 

it depends of the way the structure is filled. if the structure has a fixed size (that is, it does not contain any dynamically allocated pointer) and is self-contained (it does not contain pointers to memory outside the structure itself) then you can dump the struct directly to a file using standard library file operation. something along that way:

#include <stdio.h>

FILE *file;

file = fopen( "filename", "w" );
fwrite( &your_struct, sizeof(your_struct), 1, file )
fclose( file );

(note: error checking ommited for clarity and conciseness)

reloading looks something like this:

file = fopen( "filename", "r" );
fread( &your_struct, sizeof(your_struct), 1, file );
fclose( file );

this method will work on all platforms.

however, this method is not strictly cross-platform, since the resulting file cannot be ported between machines of different endianness (for example, old Macintosh'es used to store the bytes composing an int in a different order than an IBM PC); the resulting file can only be used on platforms of the same architecture than the computer which produced the file.

now if the struct is not self-contained (it contains a pointer referencing memory outside the struct) or uses dynamically allocated memory, then you will need something more elaborate...


regarding the endianness problem, the standard BSD socket implementation, which exists on almost every platform, defines a set of functions to convert from network byte order to host byte order (and their inverse), which are really handy, since the network byte order is strictly cross-platform. have a look at htons() and ntohs(), htonl() and ntohl(). unfortunately, you have to call those functions for each field of the structure, which is quite cumbersome if the structure is large.

Adrien Plisson
"contains a pointer referencing memory outside the struct" - for that matter if it contains a pointer referencing memory *inside* the struct, you're still in trouble. You'd need it to use an offset instead.
Steve Jessop
Oh, and regarding portability of the file it's not just endian-ness you have to worry about. You'd need the layout of the struct to be identical on both implementations, and you need the representation of each member to be identical too. Endian-ness is one aspect of representation. A local cache per machine is easier - if you want a portable representation it might be better to get a serialization library from somewhere, or use a non-binary format (YAML or something). Also beware that float values might not be portable at all (if not IEEE - the set of representable values might differ).
Steve Jessop
@Steve: thanks for completing. i tried not to over-complicate the problem: the OP talks about a cross-platform solution, but do not specify which part must be cross-platform: the serialized output file or the code which produces the output file. my solution aims at a simple cross-platform code, and tries to give some hints on what to expect for a complete cross-platform file format. i am afraid that the complete cross-platform serialization, including taking care of pointer offsets, alignement, layout and endianness, does not fit into a post that short.
Adrien Plisson
A: 

Hello LeLa,

Endianness is one issue, see "Writing endian-independent code in C" from IBM: http://www.ibm.com/developerworks/aix/library/au-endianc/index.html?ca=drs-

But you will also have to take care of "structure Padding and Alignment", see this article from C Linux Pro:

http : // clinuxpro.com/Cprogramming/structurepadding.php (sorry, Stackoverflow prevents me from using a second link, saying that this would be SPAM...)

Then, if you are careful about both issues, you can dump your data in a portable way.

Pierre
A: 

maybe you can store the data in XML-Format-File. With that you can avoid the problems Adrian told, and you also have no problem with language specific character codesets, and you even have the opportunity to read and write and handle the data in completly different programming languages

Peter Miehle