Re^3: Looking for less code

Point 1: You should run with both "warnings" and "strict" enabled.

~~Point 2: I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero".~~

Update: My comment about 'C' was not meant in a derogatory way. I stand by my assertion that code should run with both warnings and strict. Some performance increase can be obtained without warnings in well debugged code. But that was not the point here. There is a difference in general between, I know for sure that this $var is "false": ('',"",0) and I "don't know what the value is", (undef), so I am gonna assume "false".

Update: minor typo punctuation corrections.

#!/usr/bin/perl -w
use strict;

my $x = undef;
print "$x\n";
$x = 0;
print "$x\n";

#prints: 
#Use of uninitialized value $x in string at C:\TEMP\perl1.pl line 5.

0
[download]

Comment on Re^3: Looking for less code Select or Download Code

Replies are listed 'Best First'.
Re^4: Looking for less code by moritz (Cardinal) on Aug 11, 2009 at 09:22 UTC
Point 1: You should run with both "warnings" and "strict" enabled. I know. Still it's not an error, and still you should also use Data::Dumper (or better) for debugging (and then you don't even get a warning). But didn't I say that already? Point 2: I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero". How do C classes help me here? To understand that an `undef` doesn't create an IV? I also know the difference between 0 and undef in perl. How does that relate to my second point? Both evaluate to false in boolean context, without warning.	[reply] [d/l]
Re^5: Looking for less code by Marshall (Canon) on Aug 11, 2009 at 09:35 UTC
We are getting away from OP's question. I apologize for evidently starting that diversion. That was not my intent. Update: The OP wants to simplify some series of "if" statements. My personal opinion about a "false" value is that it should be a "defined value". BUT, an undef can be used in the false sense in an "if" statement!! No problem!! This will work!! If folks got the idea that I meant that "undef" did not equate to false, I certainly didn't mean that. As that is wrong! Undef will evaluate to "false". I personally think that when you assign a "false" value to a $var that "false" value should be "defined". Valid false values are single quotes '', double quotes "" and 0 and YES, undef. Using a "defined value" has advantages like when you print that $var, you don't get a run time error "undefined $var".	[reply]
Re^4: Looking for less code by JavaFan (Canon) on Aug 11, 2009 at 09:26 UTC
I recommend taking some 'C' classes and you will understand the difference between "undef" and "zero". Unlike C, in Perl, "undef" is actually a value. I really fail what insight C can give you here. In fact, I recommend you take some Perl classes, and learn what `undef` really is (and isn't).	[reply] [d/l]
Re^5: Looking for less code by Anonymous Monk on Aug 11, 2009 at 09:28 UTC
Powerful poetry `undef JavaFan` [download] Can't modify constant item in undef operator :)	[reply] [d/l]
Re^6: Looking for less code by Marshall (Canon) on Aug 11, 2009 at 09:49 UTC
JavaFan, I was simply saying that using a Perl value that can't be printed as "false" is a bad idea when other options like =0 are also available. Perl is very tolerant of "undefs". That does not mean that they should be intentionally be used. "",'',0 are well defined "false" values in Perl. They can all be printed, they can all be passed to subs. "undef" means in the general sense: "undefined: I don't know". That is different than I know for sure that this is "false" instead of "true". Basically if you know that a $var is "false" you should set it to a known defined "false" value. undef is not the same thing.	[reply]