in reply to Re^3: Subroutine references inside of a hash with arguments.
in thread Subroutine references inside of a hash with arguments.

I don't think that there are any at all.

See warnings.

Strict is a compile time thing - not run time.

The strict documentation disagrees:

"strict refs" ... generates a runtime error if you use symbolic references (see perlref).
Scoping like "my vars" is a big part of what "use strict" enforces....

As I wrote in my previous message, you can avoid lexical variables altogether (and avoid lexical scoping altogether) and satisfy strict. Did you try it? You can also declare all of your lexical variables at package-level scope and satisfy strict. strict has nothing to do with scoping (except that strict's area of effect is lexical).

... in general when you call a sub, you push things onto a stack and the sub consumes them by shifting them off the stack, just like with any other main programming language....

I can think of multiple machines -- virtual and otherwise -- where that's not true.

  • Comment on Re^4: Subroutine references inside of a hash with arguments.

Replies are listed 'Best First'.
Re^5: Subroutine references inside of a hash with arguments.
by Marshall (Canon) on Jul 27, 2009 at 18:41 UTC
    I was not precise regarding strict and warnings. Neither one of these things is purely compile time or run time.

    "strict" has 3 categories:
    - refs
    - vars
    - subs

    'refs' has to do with symbolic references and YES, is a runtime warning. The other two: vars and subs are compile time checks. Far and away the most frequent thing that I see with "strict" is a 'vars' error, problem. 'subs' just disallows barewords.

    my $ref ="foo"; #symbolic reference to some global variable
print $$ref;    #this sort of thing is what strict 'refs' won't like

    [download]
    I would argue that although this check happens at runtime, the use of symbolic references is so seldom and what Perl does to check this is so fast that this is just lost in the overall performance scheme of things. Essentially if you don't have any symbolic references, checking happens at compile time. I think one would be hard pressed to find any program what runs significantly slower when "using strict;"

    On the other hand "use warnings;" turns out not to be purely runtime either. There are some compile time aspects to this in addition to the run time checks. However the "main event" are the runtime checks. And there are a whole bunch of them! Take a gander at the section on warnings in Chapter 31 of "Programming Perl", the is a cool diagram showing the categories.

    I have read that performance hit could be as much as 30% in some outlier cases with "use warnings". I personally have not spent a lot of time worrying about this or benchmarking code, because I feel that the benefits of using both strict and warnings outweigh any kind of performance hit entailed.

    So I guess the most accurate statement would be that "use strict" happens mainly at compile time and "use warnings" happens mainly at runtime.

[reply]
[d/l]

In Section Seekers of Perl Wisdom