Re^5: vec overflow?

A matter of taste ...

for me

vec( $_, $offset, $size ) = 1 for substr( $astring, $start, $len );

has no big advantage over

vec( substr( $astring, $start, $len ), $offset, $size ) = 1;

but

for my $chunk ( substr( $astring, $start, $len ) ) {
  ...
  vec( $chunk, $offset, $size ) = 1;
  ...
}
[download]

looks better for me than de/referencing and has the advantage to be documented in the docs.

And your use of \ substr( $astring, $start, $len ); is less frequent and makes me wondering about precedences.

(The practice to reference lvalues is still somehow new for me...)

OTOH your approach has the (dis?)advantage that the ref can be passed around w/o being restricted to the body of a for loop...

Well ... I'll better continue meditating about it after seeing more use cases! :)

Cheers Rolf

( addicted to the Perl Programming Language)

Comment on Re^5: vec overflow? Select or Download Code

Replies are listed 'Best First'.
Re^6: vec overflow? by BrowserUk (Patriarch) on Jun 25, 2013 at 14:18 UTC
`vec( $_, $offset, $size ) = 1 for substr( $astring, $start, $len );` has no big advantage over `vec( substr( $astring, $start, $len ), $offset, $size ) = 1;` I agree. But I've only very recently 'discovered' nested lvalue subs -- this thread is the first time I've ever used the construct publicly -- and I've never seen it used anywhere else. I can well imagine that there are lot of silent readers looking at `vec( vec( ... ), ... ) = 1;` `vec( substr(... ), ... ) = 1;` `substr( vec( ... ), ... ) = $stuff;` `substr( substr( ...), ... ) = $stuff;` `substr( vec( substr( vec( substr( ...), ... ), ... ), ... ), ... ) = $something;` and thinking: "I'd never use such an unholy constructs even if it meant my code running a 1000 times more slowly." With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply] [d/l] [select]
Re^7: vec overflow? by LanX (Saint) on Jun 25, 2013 at 14:32 UTC
Perl never stops to surprise ... I also learned new things again. =) > I'd never use such an unholy constructs Unholy constructs are like exorcism, only experienced priests should be allowed to and only behind closed doors (subs). Who cares how an imported sub `bigvec` does the workaround as long as it works and is well documented, i.e. has pointers to the perldoc? Cheers Rolf ( addicted to the Perl Programming Language)	[reply] [d/l]