strict and warnings

[Robin]

btw, I am reading this stuff.

I still don't understand strict and warnings...
I'm kinda a newbie...
can someone explain if this is right... whe you use strict, you have to
define your variables and then call your subroutines without ands (&) and
when you use strict and warnings together it will allow you to call your
subrountines this way, is there anything else you have to do once your using
strict and/or warnings?

Thanks,
-Robin

 

[Jürgen Exner]

I still don't understand strict and warnings...
I'm kinda a newbie...
can someone explain if this is right... whe you use strict, you have
to define your variables
Yes

and then call your subroutines without ands
(&)

Has nothing to do with strictures

and when you use strict and warnings together it will allow you
to call your subrountines this way,

Which way?

is there anything else you have
to do once your using strict and/or warnings?

Why don't you check the documentation:

perldoc strict
perldoc warnings

jue

 

[Robin]

Has nothing to do with strictures


Which way?

the way I mentioned before... without operands...
thanks,
-Robin

 

[Jürgen Exner]

the way I mentioned before... without operands...

From perldoc perlsub:

To call subroutines:

NAME(LIST); # & is optional with parentheses.
NAME LIST; # Parentheses optional if predeclared/imported.
&NAME(LIST); # Circumvent prototypes.
&NAME; # Makes current @_ visible to called subroutine.
[...]
A subroutine may be called using an explicit "&" prefix. The "&" is
optional in modern Perl, as are parentheses if the subroutine has been
predeclared. The "&" is *not* optional when just naming the subroutine,
such as when it's used as an argument to defined() or undef(). Nor is it
optional when you want to do an indirect subroutine call with a
subroutine name or reference using the "&$subref()" or "&{$subref}()"
constructs, although the "$subref->()" notation solves that problem. See
the perlref manpage for more about all that.

Subroutines may be called recursively. If a subroutine is called using
the "&" form, the argument list is optional, and if omitted, no "@_"
array is set up for the subroutine: the "@_" array at the time of the
call is visible to subroutine instead. This is an efficiency mechanism
that new users may wish to avoid.

&foo(1,2,3); # pass three arguments
foo(1,2,3); # the same

foo(); # pass a null list
&foo(); # the same

&foo; # foo() get current args, like foo(@_) !!
foo; # like foo() IFF sub foo predeclared, else "foo"

Not only does the "&" form make the argument list optional, it also
disables any prototype checking on arguments you do provide. This is
partly for historical reasons, and partly for having a convenient way to
cheat if you know what you're doing. See the Prototypes manpage below.

jue

 

[Robin]

7

the way I mentioned before... without operands...

From perldoc perlsub:

To call subroutines:

NAME(LIST); # & is optional with parentheses.
NAME LIST; # Parentheses optional if predeclared/imported.
&NAME(LIST); # Circumvent prototypes.
&NAME; # Makes current @_ visible to called subroutine.
[...]
A subroutine may be called using an explicit "&" prefix. The "&" is
optional in modern Perl, as are parentheses if the subroutine has been
predeclared. The "&" is *not* optional when just naming the subroutine,
such as when it's used as an argument to defined() or undef(). Nor is it
optional when you want to do an indirect subroutine call with a
subroutine name or reference using the "&$subref()" or "&{$subref}()"
constructs, although the "$subref->()" notation solves that problem. See
the perlref manpage for more about all that.

Subroutines may be called recursively. If a subroutine is called using
the "&" form, the argument list is optional, and if omitted, no "@_"
array is set up for the subroutine: the "@_" array at the time of the
call is visible to subroutine instead. This is an efficiency mechanism
that new users may wish to avoid.

&foo(1,2,3); # pass three arguments
foo(1,2,3); # the same

foo(); # pass a null list
&foo(); # the same

&foo; # foo() get current args, like foo(@_) !!
foo; # like foo() IFF sub foo predeclared, else "foo"

Not only does the "&" form make the argument list optional, it also
disables any prototype checking on arguments you do provide. This is
partly for historical reasons, and partly for having a convenient way to
cheat if you know what you're doing. See the Prototypes manpage below.

jue

Thanks...Robin

 

[Jonathan Stowe]

the way I mentioned before... without operands...

Er, I think you mean *ampersands*. But that is besides the point. The
use of the strict or warning pragmas has no bearing on how you call your
subroutines with one exception, that is if you call a subroutine as
a bareword (i.e. without ampersand or parentheses) before the
declaration of the subroutine in the program file when strict is in
operation you will get get a different error message than if it isn't
i.e :

Bareword "foo" not allowed while "strict subs" in use at strict.pl line
4.
Execution of strict.pl aborted due to compilation errors.

With strict, and

Unquoted string "foo" may clash with future reserved word at strict.pl
line 5.
Useless use of a constant in void context at strict.pl line 5.

Without.

Just do it. Lose the ampersands and use parentheses instead and then use
strict and warnings and fix all the problems they throw up and you'll
feel so much better for it.

/J\