Re: (tye)Re2: Why isn't "0\n" false?

Oops, I edited the wrong line, and didn't notice I still had the 0+ in there. I'm sure we all know how that goes...☺

But, here's another question. A value is not converted when boolean context is needed, OK. But what if it is a value that has both numeric and string "slots" filled? Which does it use? My guess is it looks at the string, so that "0 but true" is still true even after it's been used in a numeric expression (filling the number slot with 0).

—John

Comment on Re: (tye)Re2: Why isn't "0\n" false?

Replies are listed 'Best First'.
(tye)Re3: Why isn't "0\n" false? by tye (Sage) on Jul 27, 2001 at 23:23 UTC
Yes, it looks at the string. Like you said, it can't look at the number part or: `my $val= "0 "; my $dummy= 0+$val; print "True\n" if $val;` [download] would print "True". This is recorded in the source code in at least 4 places (for speed reasons). Each version boils down to these tests, in order: undef is false (references are true unless they reference a destroyed thing) strings are false if-and-only-if they are "" or "0" integers are false if-and-only-if they are 0 (zero) reals are false if-and-only-if they are 0.0 (zero) That second item is in parens because it only occurs in one copy of this algorithm. It doesn't matter much because I think the only way to get a reference to a destroyed item is during "global destruction". But it did make me curious about a possible low-impact bug which turned out to not exist because of something more interesting: Every time you use a reference in a string context, the resulting string is reconstructed from scratch. When you use a number in a string context, the string representation of that number is computed and then cached inside the scalar so future uses of that (formerly number-only) scalar in a string context don't have to repeat that work. This optimization is not applied to references. - tye (but my friends call me "Tye")	[reply] [d/l]

Replies are listed 'Best First'.

(tye)Re3: Why isn't "0\n" false?
by tye (Sage) on Jul 27, 2001 at 23:23 UTC

Yes, it looks at the string. Like you said, it can't look at the number part or:

my $val= "0 ";
my $dummy= 0+$val;
print "True\n"   if  $val;
[download]

in order

undef is false
(references are true unless they reference a destroyed thing)
strings are false if-and-only-if they are "" or "0"
integers are false if-and-only-if they are 0 (zero)
reals are false if-and-only-if they are 0.0 (zero)

That second item is in parens because it only occurs in one copy of this algorithm. It doesn't matter much because I think the only way to get a reference to a destroyed item is during "global destruction".

But it did make me curious about a possible low-impact bug which turned out to not exist because of something more interesting: Every time you use a reference in a string context, the resulting string is reconstructed from scratch. When you use a number in a string context, the string representation of that number is computed and then cached inside the scalar so future uses of that (formerly number-only) scalar in a string context don't have to repeat that work. This optimization is not applied to references.

tye

[reply]
[d/l]