Re: Clarity in parsing fixed length data.

Update: As pointed out below, this doesn't work! Sorry, A rush of blood I think.

If you used a hash to contain your spec:

my %TEST_REC_PACK_FLDS = {
   status => 'n  ',   #   0
   time   => 'n  ',   #   2
   date   => 'N  ',   #   4
   code   => 'a16',   #   8   key
   msid   => 'a10',   #  24   key
};
[download]

Then your field names becomes just

use constant @TEST_FLDS => keys %TEST_REC_PACK_FLDS;
[download]

and you build your format string using

use constant TEST_REC_PACK => $join ' ', values %TEST_REC_PACK_FLDS;
[download]

You might want to uppercase the field names.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re: Clarity in parsing fixed length data. Select or Download Code

Replies are listed 'Best First'.
Re^2: Clarity in parsing fixed length data. by runrig (Abbot) on Aug 10, 2006 at 22:12 UTC
If you need your keys to be in a certain order, then I wouldn't use a hash in this way (unless it's one of those tied hash modules). An array is the appropriate thing here.	[reply]
Re^2: Clarity in parsing fixed length data. by ikegami (Patriarch) on Aug 10, 2006 at 22:12 UTC
Field order is lost by using a hash.	[reply]
Re^2: Clarity in parsing fixed length data. by rodion (Chaplain) on Aug 10, 2006 at 22:18 UTC
Thanks, I meant to mention that the order of the fields is important for the list of field names. (I've added an update mentioning that.) I considered using tied hashes that preserve order, but thought that would be less clear. If I just needed to preserve the order of the unpack spec, I could also use the "@0 n @2 n @4 N @8 a16 ..." form of unpack() specs, but the fieldname order is also useful to us.	[reply]