Below is a simplified version of a perl script I am trying to modify:
use MODULE_1 ;
use MODULE_2 ;
use vars qw(%ARR $VarZZ) ;
sub A {
# Somestuff
# Call to Sub B
B() ;
# Call to Sub C
C() ;
}
BEGIN {
package XYZ ;
use vars qw($VarYY $VarXX) ;
# MISC SUBS HERE
# end of package XYZ
}
sub B {
# Somestuff
}
sub C {
# Somestuff to set %ARR
}
# Call to Sub A
A() ;
My issue is that I will like to access %ARR within the package XYZ BEGIN block but keep getting error messages saying I need to define %ARR ("requires explicit package name")
I have tried, trying to copy a similar example within the block, $main::ARR{index} but failed so far.
I assume it may be because %ARR isn't set when that block is begin evaluated and that I need to call "sub C" perhaps but &main::C(); seems to be failing as well.
How can I access this array there?
I have looked at: Perl's main package - block syntax - pragmas and BEGIN/END blocks which seems to be addressing similar themes but struggling to properly understand the answers
** EDIT **
Expanded skeleton script showing some attempts at moving forward:
use MODULE_1 ;
use MODULE_2 ;
use vars qw(%ARR $VarZZ) ;
sub A {
# Somestuff
# Call to Sub B
B() ;
# Call to Sub C
C() ;
# Call to Sub E
E() ;
}
sub E {
# Call to Package XYZ subs
}
BEGIN {
package XYZ ;
use vars qw($VarYY $VarXX %ARR) ;
# I tried to Call to Sub C and load a local version of %ARR
#
# This fails with "Undefined subroutine &main::C" error
&main::C() ;
#
# We never get here so not sure if correct
%ARR = &main::ARR ;
# MISC SUBS HERE
sub X {
# Call to Sub D
&main::D() ;
}
# end of package XYZ
}
sub B {
# Somestuff
}
sub C {
# Somestuff to set %ARR
}
sub D {
# Somestuff
}
# Call to Sub A
A() ;
Note the the call to &main::E() works when called within the Subs in Package XYZ but both this and &main::C() fail when running free standing. Perhaps the free standing call is done at complile time before the subs are defined.
BTW, I tried the our definition but getting a 502 error: Nginx Debug Log
Perhaps this is because the array is not available?
%main:ARR or $main::ARR{index} are correct for the code skeleton you have provided (well, anything is correct because you haven't said use strict, but anyway ...). Is it possible that main is not the correct namespace (i.e., is there some pacakge statement that precedes use vars ...) ?
In any case, you can workaround this issue with the our keyword. If you declare it at the top level, it will have scope throughout the rest of the file:
package ABC;
our %ARR; # %ABC::ARR
sub foo {
$ARR{"key"} = "value"; # %ABC::ARR
}
{ # "BEGIN" optional
package XYZ;
our %Hash; # %XYZ::Hash
sub bar {
my $key1 = $Hash{"key1"}; # %XYZ::Hash
my $val1 = $ARR{$key1}; # %ABC::ARR
$ARR{$val1} = $key1;
}
}
...
Related
I have been assigned such a problem in my software development course. So, the normal way is to check each procedure one by one and remember each call by each subprogram, however, I am a bit lazy programmer and I have decided to take a shortcut by implementing given pseudocode in an actual programming language.
Problem statement:
procedure Main is
X, Y, Z : Integer;
procedure Sub1 is
A, Y, Z : Integer;
begin
...
end;
procedure Sub2 is
A, B, Z : Integer;
begin
...
procedure Sub4 is
A, B, W : Integer;
begin
...
end;
end;
procedure Sub3 is
A, X, W : Integer;
begin
...
end;
begin
...
end;
Consider the program above. Given the following calling sequences and assuming that
dynamic scoping is used, what variables are visible during the execution of the last subprogram
activated? Include with each visible variable the name of the unit where it is declared (e.x. Main.X).
Main calls Sub1; Sub1 calls Sub3; Sub3 calls Sub2;
My Attempt:
$x = 10;
$y = 20;
$z = 30;
sub Sub2
{
return $x;
}
sub Sub1
{
local $x = 9;
local $y = 19;
local $z = 29;
return Sub2();
}
print Sub1()."\n";
I'm stuck at this point and have no idea how to change the code so that it shows me the variables. I see that solution is obvious, but I've coded in C++ and Java so far.
It would be nice if you've spent the time you used on asking this question on watching tutorials. However, we all have been there at one point, being confused exploring new languages. Try not to ask for the answer to your homework next time.
So, I see you'd like to use Perl, a good choice. I myself have done a similar task recently, here is my approach.
As R. Sebesta (2019) writes in the book named "Concepts of Programming
Languages" (12 ed.), the best examples of dynamic scoping are Perl and
Common Lisp.
Basically, it is based on the sequence of subprogram calls which are determined only at run time.
The following program shows how the subprogram calls affect variable value:
$x = 0;
$y = 0;
$z = 0;
sub sub1
{
local $a = 1;
local $y = 1;
local $z = 1;
return sub3();
}
sub sub2
{
local $a = 2;
local $b = 2;
local $z = 2;
sub sub4
{
local $a = 4;
local $b = 4;
local $w = 4;
}
return "Sub".$a.".A, "."Sub".$b.".B, "."Sub".$w.".W, "."Sub".$x.".X,
"."Sub".$y.".Y, "."Sub".$z.".Z";
}
sub sub3
{
local $a = 3;
local $x = 3;
local $w = 3;
return sub2();
}
print sub1()."\n";
Output: Sub2.A, Sub2.B, Sub3.W, Sub3.X, Sub1.Y, Sub2.Z
Note: Sub0 is just Main subprogram scope.
If you want to check the values of the variables in each subroutine you would dump them out with a module like Data::Dump or Data::Dumper.
sub foo {
printf "foo() current values are %s\n\n",
Data::Dumper::Dumper($a, $b, $c, $x, $y, $z);
}
If you want to see the call stack of the current subroutine you would use the Carp module.
use Carp;
sub foo { Carp::cluck("foo() here"); }
sub bar { foo() }
&bar;
# Output
foo() here at (eval 284) line 1.
W::foo() called at (eval 284) line 1
W::bar() called at (eval 285) line 1
eval 'package W; bar' called at script.pl line 116
console::_console called at script.pl line 473
I have a problem about variables of a subroutine which cannot be accessed by another subroutine.
the first subroutine :
sub esr_info {
my $esr ;
my #vpls = () ;
my #sap = ();
my #spoke = () ;
&conf_esr($esr , 1);
}
the second :
sub conf_esr {
my $e = #_[0] ;
some code (#vpls, #sap, #spoke);
}
the first calls the second, and I need the variables of the first to be local and not global for the whole code (for threading purposes). The second uses all the variables of the first . I get these errors :
Global symbol "$esr" requires explicit package name (did you forget to declare "my $esr"?) at w.pl line 63.
Global symbol "#vpls" requires explicit package name (did you forget to declare "my #vpls"?) at w.pl line 74.
My question : Can a subroutine access the vars of another without declaring those vars as global ?
Many thanks for reading the post.
You can contain (restrict the visibility of) the variables to the two subs by introducing a scope { ... }, for example:
{
my $esr ;
my #vpls = () ;
my #sap = ();
my #spoke = () ;
sub esr_info {
conf_esr($esr , 1);
}
sub conf_esr {
my $e = #_[0] ;
#some code (#vpls, #sap, #spoke);
}
}
But note that the variables now retain the values after the subs are exited (they become state variables). This is also called a closure.
But other approaches could be more appropriate (closures can make the code more difficult to read and hence to maintain) depending on you situation. For example, alternatives could be:
you could pass references to the variables as arguments to conf_esr, or better
use an object oriented approach where the variables are contained in a $self hash.
My question : Can a subroutine access the vars of another without declaring those vars as global ?
No. You should try passing in variables, it's better form, but you can also use global variables.
my $i=1;
mysub(); # This will not change the global $i
print "i=$i\n"; # This should print '1'
exit;
##########
sub mysub
{my $i=2; # This is a variable local to mysub() only.
return;
}
Type in the code above and run it with Perl. Notice that the $i in the subroutine mysub() is completely different than the global $i in the program itself, because the $i in the mysub() is a different memory address.
Now let's change $i to global. mysub() will change the global $i because it doesn't have a local $i declared.
my $i=1;
mysub(); # This will not change the global $i
print "i=$i\n"; # This should print '2'
exit;
##########
sub mysub
{$i=2; # This is changing the value in the global $i memory area.
return;
}
Given the following Perl program:
package Foo;
use strict;
use warnings;
sub new {
my ($class) = #_;
return bless {}, $class;
}
sub c {
print "IN ORIG C\n";
}
sub DESTROY {
print "IN DESTROY\n";
c();
}
1;
package main;
use strict;
use warnings;
no warnings qw/redefine once/;
local *Foo::c = sub { print "IN MY C\n" };
my $f = Foo->new();
undef $f;
I expect output as:
IN DESTROY
IN MY C
But I actually get output as:
IN DESTROY
IN ORIG C
Q: Why is my localized redefinition of Foo::c not taking effect?
When perl code is compiled, globs for package variables/symbols are looked up (and created as necessary) and referenced directly from the compiled code.
So when you (temporarily) replace the symbol table entry for *Foo::c at runtime, all the already compiled code that used *Foo::c still uses the original glob. But do/require'd code or eval STRING or symbolic references won't.
(Very similar to Access package variable after its name is removed from symbol table in Perl?, see the examples there.)
This is a bug in perl which will be fixed in 5.22 (see Leon's comment below).
This happens because undef $f; doesn't actually free up and destroy $f, it just marks it as ready to
be freed by a nextstate op.
nextstate ops exist roughly between each statement, and they are there
to clean up the stack, among other things.
In your example, since undef $f is the last thing in the file, there
is no nextstate after it, so your local destructor goes out of scope
before $f's destructor is called (or, the global destruction that
happens just isn't aware of your local change.)
When you add a print statement after undef $f, the nextstate op
before the print calls your local destructor.
You can see the additional nextstate in your example at
https://gist.github.com/calid/aeb939147fdd171cffe3#file-04-diff-concise-out.
You can also see this behaviour by checking caller() in your DESTROY method:
sub DESTROY {
my ($pkg, $file, $line) = caller;
print "Destroyed at $pkg, $file, $line\n";
c();
}
mhorsfall#tworivers:~$ perl foo.pl
Destroyed at main, foo.pl, 0
IN DESTROY
IN ORIG C
mhorsfall#tworivers:~$ echo 'print "hi\n"' >> foo.pl
mhorsfall#tworivers:~$ perl foo.pl
Destroyed at main, foo.pl, 30
IN DESTROY
IN MY C
hi
(Line 30 being the print "hi\n")
Hope that sheds some light on this.
Cheers.
The problem here doesn't have to do with compile time vs runtime but rather with scoping.
The use of local limits the scope of your modified Foo::c to the remainder of the current scope (which in your example is the remainder of your script). But DESTROY doesn't run in that scope, even when you explicitly undef $f (See http://perldoc.perl.org/perlobj.html#Destructors for more discussion of the behavior of DESTROY). It runs at an undetermined time later, specifically AFTER $f has "gone out of scope". Therefore, any localized changes you have made in the scope of $f will not apply whenever DESTROY finally runs.
You can see this yourself by simply removing the local in your example:
With local
IN DESTROY
IN ORIG C
Without local
IN DESTROY
IN MY C
Or by adding a few additional subroutines and calling them in package::main scope:
package Foo;
...
sub d {
c();
}
sub DESTROY {
print "IN DESTROY\n";
c();
}
1;
package main;
...
sub e {
Foo::c();
}
local *Foo::c = sub { print "IN MY C\n" };
my $f = Foo->new();
Foo::c();
Foo::d();
e();
undef $f;
Which prints
IN MY C
IN MY C
IN MY C
IN DESTROY
IN ORIG C
So only in DESTROY is the original c used, further demonstrating that this is a scoping issue.
Also see https://stackoverflow.com/a/19100461/232706 for a great explanation of Perl scoping rules.
I saw this question: Is there any difference between "standard" and block package declaration? and thinking about the main package. When I write a script, like:
---- begin of the file ---
#!/usr/bin/perl #probably removed by shell?
my $var; #defined from now up to the end of file
...
---- end of the file ----
this automatically comes into the main package, so as I understand right the next happens.
---- begin of the file ---
{ #<-- 1st line
package main;
my $var; #variable transformed to block scope - "up to the end of block"
...
} # <-- last line
---- end of the file ----
which is equivalent to
---- begin of the file ---
package main { #1st line
my $var; #variable block scope
...
} #last line
---- end of the file ----
Question 1: Is the above right? That happens with the main package?
Now the BEGIN/END blocks and pragmas. There are handled in the compilation phase, if I understand right. So having:
---- begin of the file ---
#!/usr/bin/perl
use strict; #file scope
use warnings; #file scope
my $var; #defined from now up to the end of file
BEGIN {
say $var; #the $var is not known here - but it is declared
}
...
---- end of the file ----
the $var is declared, but here
---- begin of the file ---
#!/usr/bin/perl
use strict; #file scope
use warnings; #file scope
BEGIN {
say $var; #the $var is not known here - but "requires explicit package name" error
}
my $var; #defined from now up to the end of file
...
---- end of the file ----
the $var is not declared.
So how is the above translated to "default main package"?
It is always:
---- begin of the file ---
{
package main;
use strict; #block scope ???
use warnings; #block scope ???
my $var; #defined from now up to the end of block
BEGIN { #NESTED???
say $var; #the $var is not known here - but declared
}
...
}
---- end of the file ----
which is equivalent of
---- begin of the file ---
package main {
use strict; #block scope
use warnings; #block scope
my $var; #defined from now up to the end of block
BEGIN { #NESTED block
say $var;
}
...
}
---- end of the file ----
The question is - is here _ANY benefit using something like:
---- begin of the file ---
use strict; #always should be at the START OF THE FILE - NOT IN BLOCKS?
use warnings;
#not NESTED
BEGIN {
}
package main {
my $var;
}
So the question is:
how exactly are handled the pragmas, BEGIN/END/CHECK blocks and the main package in a context of BLOCK syntax?
when changes the "file scope" to the "block scope" - or if it not changes, what is the equivalent translation of "standard main package" to "main package {block}"
and the last code:
---- begin of the file ---
use strict; #always should be at the START OF THE FILE - NOT IN BLOCKS?
use warnings;
my $var;
#not NESTED
BEGIN {
}
package main {
}
How does the my $var get into the main package? So this is translated to somewhat as:
---- begin of the file ---
use strict; #always should be at the START OF THE FILE - NOT IN BLOCKS?
use warnings;
#not NESTED
BEGIN {
}
package main {
my $var; #### GETS HERE????
}
Sorry for the wall of text...
When you declare the variable with my, it is not in any package. At all. The block scope is strictly distinct from any package. The variable is valid until the closing brace (}) of the innermost enclosing block only without package qualification. If you wrote $main::var or $::var, it would be different variable.
use warnings;
use strict;
package main {
my $var = 'this';
}
$var; # error, $var was not declared in this scope
say $main::var; # says nothing
There are two more ways to declare variables:
use vars qw($var) makes $var refer to the variable in current package wherever inside the package.
our $var makes $var refer to the variable in package that was current at the time of the our statement within current block.
The block package declaration is a block and puts it's content in a package. Whereas the block-less package declaration puts following content in another package, but the current block scope continues.
The other missing bit is that when you write
use warnings;
use strict;
package main {
# ...
}
you've effectively written
package main {
use warnings;
use strict;
package main {
# ...
}
}
and since the package is the same, that's the same as
package main {
use warnings;
use strict;
{
# ...
}
}
In other words the package is main at the beginning of the file and an implicit block scope (the file scope) is open. When you re-enter main package, it has no effect and if it is associated with block, it behaves as any block.
Scope and execution order have little to do with each other.
Yes, the default package is main. So it could be said that
---- begin file ----
1: #!/usr/bin/perl
2: my $var;
3: ...;
---- end file ----
is equivalent to
package main {
---- begin file ----
1: #!/usr/bin/perl
2: my $var;
3: ...;
---- end file ----
}
It is simply that the main package is assumed unless another is specified. This does not change line numbers etc.
When a variable declaration is encountered, it is immediately added to the list of known variables. Or more precisely, as soon as the statement where it was declared has ended:
my # $var unknown
$var # $var unknown
= # $var unknown
foo() # $var unknown
; # NOW $var is declared
Similar for pragmas: An use statement is executed as soon at is fully parsed. In the next statement, all imports are available.
Blocks like BEGIN are executed outside of the normal control flow, but obey scoping rules.
BEGIN blocks are executed as soon as they are fully parsed. The return value is discarded.
END blocks are executed when the interpreter exits by normal means.
When we have
my $var = 1; # $var is now declared, but the assignment is run-time
BEGIN {
# here $var is declared, but was not assigned yet.
$var = 42; # but we can assign something if we like
}
# This is executed run-time: $var == 1
say $var;
BEGIN {
# This is executed immediately. The runtime assignment has not yet happened.
# The previous asignment in BEGIN did happen.
say $var;
}
The result?
42
1
Note that if I do not assign a new value at runtime, this variable keeps its compile time value:
my $var;
...; # rest as before
Then we get
42
42
Blocks can be arbitrarily nested:
my $var;
if (0) {
BEGIN {
say "BEGIN 1: ", ++$var;
BEGIN {
say "BEGIN 2: ", ++$var;
BEGIN { $var = 0 }
}
}
}
Output:
BEGIN 2: 1
BEGIN 1: 2
Here we can see that BEGIN blocks are executed before the if (0) is optimized away, because BEGIN is executed immediately.
We can also ask which package a block is in:
BEGIN { say "BEGIN: ", __PACKAGE__ }
say "before package main: ", __PACKAGE__;
# useless redeclaration, we are already in main
package main {
say "in package main: ", __PACKAGE__;
}
Output:
BEGIN: main
before package main: main
in package main: main
So we are in main before we redeclared it. A package is no sealed, immutable entity. It is rather a namespace we can reenter at will:
package Foo;
say "We are staring in ", __PACKAGE__;
for (1 .. 6) {
package Bar;
say "Loop $_ in ", __PACKAGE__;
if ($_ % 2) {
package Baz;
say "... and in ", __PACKAGE__;
BEGIN { say "just compiled something in ", __PACKAGE__ }
} else {
package Foo;
say "... again in ", __PACKAGE__;
BEGIN { say "just compiled something in ", __PACKAGE__ }
}
}
Output:
just compiled something in Baz
just compiled something in Foo
We are staring in Foo
Loop 1 in Bar
... and in Baz
Loop 2 in Bar
... again in Foo
Loop 3 in Bar
... and in Baz
Loop 4 in Bar
... again in Foo
Loop 5 in Bar
... and in Baz
Loop 6 in Bar
... again in Foo
So regarding this:
The question is - is here ANY benefit using something like:
---- begin of the file ---
use strict;
use warnings;
package main {
my $var;
}
The answer is no: If we are already in the package main, redeclaring it has no benefit:
say __PACKAGE__;
package main {
my $var;
say __PACKAGE__;
}
say __PACKAGE__;
If we execute that we can see we are in main the whole time.
Pragmas like strict and warnings have lexical scope, so declaring them as early as possible is good.
# no strict yet
use strict;
# strict now activated
BEGIN {
# we are still in scope of strict
$var = 1; # ooh, an undeclared variable. Will it blow up?
say "BEGIN was executed";
}
my $var;
Output:
Global symbol "$var" requires explicit package name at - line 8.
BEGIN not safe after errors--compilation aborted at - line 10.
The variable was not declared inside the BEGIN block, because it was compiled and (not quite executed) before the declaration. Therefore, strict issues this error. Because this error occurred during compilation of the BEGIN block, this block wasn't executed.
Because of scoping, you can't always reorder your source code in a way that avoids using BEGIN blocks. Here is something you should never do:
for (1 .. 3) {
my $var;
BEGIN { $var = 42 };
say $var // "undef";
}
Output:
42
undef
undef
because $var is emptied whenever the block is left. (This is probably undefined behaviour, and may possibly change. This runs under at least v5.16.3 and v5.14.2).
When your program is compiled no reordering takes place. Instead, BEGIN blocks are executed as soon as they are compiled.
For the exact times when CHECK and END are run, read through perlmod.
Given a root directory I wish to identify the most shallow parent directory of any .svn directory and pom.xml .
To achieve this I defined the following function
use File::Find;
sub firstDirWithFileUnder {
$needle=#_[0];
my $result = 0;
sub wanted {
print "\twanted->result is '$result'\n";
my $dir = "${File::Find::dir}";
if ($_ eq $needle and ((not $result) or length($dir) < length($result))) {
$result=$dir;
print "Setting result: '$result'\n";
}
}
find(\&wanted, #_[1]);
print "Result: '$result'\n";
return $result;
}
..and call it thus:
$svnDir = firstDirWithFileUnder(".svn",$projPath);
print "\tIdentified svn dir:\n\t'$svnDir'\n";
$pomDir = firstDirWithFileUnder("pom.xml",$projPath);
print "\tIdentified pom.xml dir:\n\t'$pomDir'\n";
There are two situations which arise that I cannot explain:
When the search for a .svn is successful, the value of $result perceived inside the nested subroutine wanted persists into the next call of firstDirWithFileUnder. So when the pom search begins, although the line my $result = 0; still exists, the wanted subroutine sees its value as the return value from the last firstDirWithFileUnder call.
If the my $result = 0; line is commented out, then the function still executes properly. This means a) outer scope (firstDirWithFileUnder) can still see the $result variable to be able to return it, and b) print shows that wanted still sees $result value from last time, i.e. it seems to have formed a closure that's persisted beyond the first call of firstDirWithFileUnder.
Can somebody explain what's happening, and suggest how I can properly reset the value of $result to zero upon entering the outer scope?
Using warnings and then diagnostics yields this helpful information, including a solution:
Variable "$needle" will not stay shared at ----- line 12 (#1)
(W closure) An inner (nested) named subroutine is referencing a
lexical variable defined in an outer named subroutine.
When the inner subroutine is called, it will see the value of
the outer subroutine's variable as it was before and during the first
call to the outer subroutine; in this case, after the first call to the
outer subroutine is complete, the inner and outer subroutines will no
longer share a common value for the variable. In other words, the
variable will no longer be shared.
This problem can usually be solved by making the inner subroutine
anonymous, using the sub {} syntax. When inner anonymous subs that
reference variables in outer subroutines are created, they
are automatically rebound to the current values of such variables.
$result is lexically scoped, meaning a brand new variable is allocated every time you call &firstDirWithFileUnder.
sub wanted { ... } is a compile-time subroutine declaration, meaning it is compiled by the Perl interpreter one time and stored in your package's symbol table. Since it contains a reference to the lexically scoped $result variable, the subroutine definition that Perl saves will only refer to the first instance of $result. The second time you call &firstDirWithFileUnder and declare a new $result variable, this will be a completely different variable than the $result inside &wanted.
You'll want to change your sub wanted { ... } declaration to a lexically scoped, anonymous sub:
my $wanted = sub {
print "\twanted->result is '$result'\n";
...
};
and invoke File::Find::find as
find($wanted, $_[1])
Here, $wanted is a run-time declaration for a subroutine, and it gets redefined with the current reference to $result in every separate call to &firstDirWithFileUnder.
Update: This code snippet may prove instructive:
sub foo {
my $foo = 0; # lexical variable
$bar = 0; # global variable
sub compiletime {
print "compile foo is ", ++$foo, " ", \$foo, "\n";
print "compile bar is ", ++$bar, " ", \$bar, "\n";
}
my $runtime = sub {
print "runtime foo is ", ++$foo, " ", \$foo, "\n";
print "runtime bar is ", ++$bar, " ", \$bar, "\n";
};
&compiletime;
&$runtime;
print "----------------\n";
push #baz, \$foo; # explained below
}
&foo for 1..3;
Typical output:
compile foo is 1 SCALAR(0xac18c0)
compile bar is 1 SCALAR(0xac1938)
runtime foo is 2 SCALAR(0xac18c0)
runtime bar is 2 SCALAR(0xac1938)
----------------
compile foo is 3 SCALAR(0xac18c0)
compile bar is 1 SCALAR(0xac1938)
runtime foo is 1 SCALAR(0xa63d18)
runtime bar is 2 SCALAR(0xac1938)
----------------
compile foo is 4 SCALAR(0xac18c0)
compile bar is 1 SCALAR(0xac1938)
runtime foo is 1 SCALAR(0xac1db8)
runtime bar is 2 SCALAR(0xac1938)
----------------
Note that the compile time $foo always refers to the same variable SCALAR(0xac18c0), and that this is also the run time $foo THE FIRST TIME the function is run.
The last line of &foo, push #baz,\$foo is included in this example so that $foo doesn't get garbage collected at the end of &foo. Otherwise, the 2nd and 3rd runtime $foo might point to the same address, even though they refer to different variables (the memory is reallocated each time the variable is declared).