Re: slurped scalar map

You could use lvalue refs:

#! perl -slw
use strict;

my $data = <<EOD;
record 1
record 2 is a bit longer
record 3 is just this length
EOD

my $p = 0;
my @refs;

while( my $o = 1+index $data, "\n", $p ) {
    push @refs, \substr $data, $p, $o - $p;
    $p = $o
}

print $$_ for @refs;
[download]

which works okay (from 5.8.4 (maybe 5.8.3 I forget) onwards), but don't try assigning to them unless your replacements are exactly the same length as the originals.

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: slurped scalar map Download Code

Replies are listed 'Best First'.
Re^2: slurped scalar map by 0xbeef (Hermit) on Jun 20, 2006 at 21:26 UTC
Thanks, this elaborates on your analysis as johngg mentioned. I do not have fixed record seperators but I do have records of variable length/content so I rely on offset and size. I intend to use your example based on calculating each record's end offset: `#!/usr/bin/perl -slw use strict; my $data = <<EOD; record 1 is 20 bytesrecord 2 is 20 bytesrecord 3 is longer at 30 bytes EOD my $p = 0; my @refs; # endpos would be calculated based on recsize - this is simplified: my @endpos=(20,40,70); for (@endpos) { push @refs, \substr $data, $p, $_ - $p; $p = $_; } print '[',$$_,']' for @refs;` [download] Hope I got that right. Niel	[reply] [d/l]
Re^3: slurped scalar map by BrowserUk (Patriarch) on Jun 21, 2006 at 07:36 UTC
Just be aware that even this method will only save you space where your records are longer than (from memory) 12 characters. And if you are having to store another array containing the record length, then you have to factor the size of that array into the argument as well unless you replace each record length with the lvalue ref of the record as you go. The space consumed storing the lengths will depend upon whether the numeric values are loaded and stored as IVs or PVs. Around 20 bytes/length for the former and approx. 50 for the later in addition to that used to store the lvalue ref. Also, it only makes sense to build an array of refs if you are going to randomly access each (or some) records more than once. Otherwise, it would be better to simply generate and use an lvalue ref for each record as you need it. The trade-off between replacing the lengths with lvalue refs, and generatng them on the fly will depend upon the number and frequency with which you re-access records through the life of the program; how the length are loaded etc. 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.	[reply]


go ahead... be a heretic
	PerlMonks