Re: Opening certain files

To expand on ikegami's comment, you should be careful of packing. You might know this, and apologies if you do, but members of a struct might have pad bytes added by the compiler to force those members onto boundaries, depending on the type. For example:

struct mystruct {
    char a;
    int b;
    char c;
};
[download]

would be 12 bytes on many 32-bit compilers, adding 3 bytes after each char to align the int on a word bounday, and to make the struct a whole number of words. You have to be aware of the padding which can vary between compilers, command-line options, and pragmas (some compilers support #pragma packed).

If it was me then I would write a wrapper in XS to read the C++ output, but then I am a sucker for making work for myself.

Comment on Re: Opening certain files Select or Download Code

Replies are listed 'Best First'.
Re^2: Opening certain files by locked_user sundialsvc4 (Abbot) on Nov 09, 2010 at 13:54 UTC
I certainly would consider that approach in, for example, a module that might be deployed on different computers. If you know that the file layout is (and will forever remain) stable, as will the source of that data file, then you might reasonably get away with using `pack/unpack`, which of course is designed expressly for this sort of thing. Any such program should aggressively check for errors in the input, particularly any which imply that the unpack-information does not coincide with the data. Realistically, only the computer itself can guard against “garbage in, garbage ~~out~~ stay forever” in this case. The input program is the entire system’s first line of defense, and so it should treat every record as “`Fubar` until proven otherwise.” (The “inefficiency” (sic) of doing this should be of no concern whatever.)

Replies are listed 'Best First'.

Re^2: Opening certain files
by locked_user sundialsvc4 (Abbot) on Nov 09, 2010 at 13:54 UTC

I certainly would consider that approach in, for example, a module that might be deployed on different computers. If you know that the file layout is (and will forever remain) stable, as will the source of that data file, then you might reasonably get away with using pack/unpack, which of course is designed expressly for this sort of thing.

Any such program should aggressively check for errors in the input, particularly any which imply that the unpack-information does not coincide with the data. Realistically, only the computer itself can guard against “garbage in, garbage ~~out~~ stay forever” in this case. The input program is the entire system’s first line of defense, and so it should treat every record as “Fubar until proven otherwise.” (The “inefficiency” (sic) of doing this should be of no concern whatever.)