Inline regex

[Michele Dondi]

That's two lines!

my ($desc) = map {local $_ = $_; s/\s+$//; $_} $line [7];

I often use C<local $_> myself, but I'm somewhat wary about it since
clpmisc informed me that it can be buggy with tied stuff, althoug I
doubt that $line [7] will contain any.


Michele

 

[Gunnar Hjalmarsson]

That's two lines!

my ($desc) = map {local $_ = $_; s/\s+$//; $_} $line [7];

I often use C<local $_> myself, but I'm somewhat wary about it since
clpmisc informed me that it can be buggy with tied stuff,

Isn't that why it's better written

my ($desc) = map { local *_ = \$_; s/\s+$//; $_ } $line[7];
-----------------------------^----^

 

[Tad McClellan]

steve wrote:

am constantly removing trailing whitespace like so:

(my $desc = $line[7]) =~ s/\s+$//;

Would the code you suggested remove the whitespace from $line[7] as well?

What happened when you tried it?

 

[Tad McClellan]

Another quick question...

Then you should start a new thread.

I have a variable that is padded with leading zeros (e.g. "0001.125"). I
want to be able to remove all leading zeros if the value >= 1 ("1.125"),
but leave one leading zero if the value < 1 (e.g. "0000.125" should
become "0.125" not ".125"). Can I do this with one regex?

$num =~ s/^0+(\d)/$1/;

 

[Mirco Wahab]

MW> Where the 'map' would (imho) make sense:
MW> ...
MW> my @trimmed = map /\s+$/ ? substr($_,0,$-[0]) : $_, @line;
MW> ...

why the extra code? just grab the text before the trailing spaces (untested):

This was made for "speedy design". I had "a million" of "big strings"
in mind - and tried to provide a practical, nondestructive version
that avoids unnecessary copying (see my last remark in my posting).

my @trimmed = map /^(.*?)\s*$/, @line;

note the use of * in both parts as either can be empty. dunno if this
will run fast or slow due to the double use of *. but as i said in
another thread, trimming white space is so trivial in perl so why waste
effort on doing it in different ways.

If you have a production system that runs often, you may
optimize at one point because it runs better
everytime then ;-)

(The best "destructive" solution would possibly involve a
direct shortening of the SV* after /\s+$/ without copying
anything around.)

Regards

Mirco

 

[Uri Guttman]

MW> Where the 'map' would (imho) make sense:
MW> ...
MW> my @trimmed = map /\s+$/ ? substr($_,0,$-[0]) : $_, @line;
MW> ...
MW> This was made for "speedy design". I had "a million" of "big strings"
MW> in mind - and tried to provide a practical, nondestructive version
MW> that avoids unnecessary copying (see my last remark in my posting).

first rule of perl optimization is don't guess which is faster,
benchmark it. my experience says that running more perl code such as the
condition expression is slower than staying inside c in one m// op. but
there are many counterexamples to that (the famous trim front and back
code). the overhead for the copy may be less than the work done in the
extra perl code. also the length of the strings and how much is copied
will affect things. i just was showing a way do it with less perl code
on the good chance that it would be faster (definitely cleaner code IMO
too). and the idiom of mapping over list with a grabbing regex is a good
one to show and teach.

uri

 

[Brian McCauley]

_
Michele Dondi ([email protected]) wrote on VCLIX September MCMXCIII
in <URL:<>
<> >That's two lines!
<> >
<> > my ($desc) = map {local $_ = $_; s/\s+$//; $_} $line [7];
<>
<> I often use C<local $_> myself, but I'm somewhat wary about it since
<> clpmisc informed me that it can be buggy with tied stuff, althoug I
<> doubt that $line [7] will contain any.

If $line [7] is tied, then you wouldn't know whether s/\s+$// actually
removes trailing white space.

General questions are usually not answerable if you have to account for
all possibilities of tiedness and overloading.

IMO, it's up to the implementor of the tie or overload methods to figure
out how "normal things" should be handled - the user of the normal things
shouldn't have to wonder whether something is tied or overloaded. (That
would defeat the purpose of tie and overload).

All that is true but not not the point Michele was making.

local($_) does something different if @line is tied array from what it
does if @line is not tied. There is _nothing_ that the implementor of
the class tied(@line) can do about this.

http://groups.google.com/group/comp..._frm/thread/85eb2aa2c9688c56/4ade11e9618f7b14

 

[Brian McCauley]

my ($desc) = map {local $_ = $_; s/\s+$//; $_} $line [7];

Isn't that why it's better written

my ($desc) = map { local *_ = \$_; s/\s+$//; $_ } $line[7];
-----------------------------^----^

No 'cos that still modifies $line[7]