Schrift
[thread]7279[/thread]

Globale Variable in BEGIN Block setzen: Interaktion von my, our, undef und BEGIN



<< |< 1 2 3 >| >> 26 Einträge, 3 Seiten
murphy
 2005-09-15 04:25
#58025 #58025
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
Betrachten wir den folgenden Code
Code: (dl )
1
2
3
4
5
use strict;
use warnings;
our $stuff = 0;
BEGIN { $stuff = 1; }
print "$stuff\n";

Ausgabe: 0

Zweiter Versuch:
Code: (dl )
1
2
3
4
5
use strict;
use warnings;
my $stuff = 0;
BEGIN { $stuff = 1; }
print "$stuff\n";

Ausgabe: 0

Dritter Versuch:
Code: (dl )
1
2
3
4
5
use strict;
use warnings;
my $stuff = undef;
BEGIN { $stuff = 1; }
print "$stuff\n";

Ausgabe: 1

Was passiert hier? Entweder es ist schon zu spät oder ich bin einfach zu dumm, jedenfalls kann ich mir nicht erklären, warum nicht alle drei Programme 1 ausgeben. Besonders merkwürdig finde ich die Tatsache, dass der Startwert der mit my deklarierten Variablen offenbar einen Einfluss auf das Verhalten des Codes im BEGIN Block hat.
When C++ is your hammer, every problem looks like your thumb.
format_c
 2005-09-15 11:59
#58026 #58026
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Also wenn du anstatt = .= gewendest siehst du was mit der Variable passiert. Ich finde alle Verhalten nicht wirklich merkwürdig.
Code: (dl )
1
2
3
4
5
6
7
8
use strict;
use warnings;
our $stuff .= 0;

BEGIN { $main::stuff = 1; }
print "$stuff\n";
_ _ END _ _
10


Gruß Alex\n\n

<!--EDIT|format_c|1126771278-->
pKai
 2005-09-15 13:21
#58027 #58027
User since
2005-02-18
357 Artikel
BenutzerIn
[default_avatar]
Der interessante Fall ist doch der mit der undef-Zuweisung.
Meine Erklärung wäre, dass dies wegoptimiert wird und also garnicht stattfindet, nachdem BEGIN die Variable bereits auf 1 gesetzt hat.
Deparse stüzt, so wie ich das sehe, diese Interpretation.
I sense a soul in search of answers.
format_c
 2005-09-15 13:43
#58028 #58028
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
Warum? Erst wird der Variable $stuff ein Wert zugewiesen, dann mit lexikalisiert und undefiniert. Ich bekomme na warnung bei der Ausgabe (durchaus logisch):
Code: (dl )
1
2
3
4
5
6
7
8
use strict;
use warnings;
my $stuff = undef;

BEGIN { $stuff = 1; }
print "$stuff\n";
_ _ END_ _
Use of uninitialized value in concatenation (.) or string at test.pl line 6.


Gruß Alex
murphy
 2005-09-15 14:48
#58029 #58029
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
Ah, logisch, der BEGIN Block wird natürlich ausgeführt, bevor die andere Zuweisung zu der Variablen erfolgt.

Allerdings bleiben da folgende Fragen bei mir offen:

- wenn der BEGIN Block zuerst ausgeführt wird, warum gibt es dann trotz use strict keine Probleme mit der Zuweisung an eine nicht näher qualifizierte Globale Variable?

(edit:
Der folgende Code
Code: (dl )
1
2
3
use strict;
use warnings;
BEGIN { $stuff = 0; }

funktioniert ja auch nicht ohne Fehler, schreibt man aber ein my $stuff oder our $stuff vor den BEGIN Block, dann beschwert sich Perl nicht mehr...)

- wenn das my $stuff = undef nach dem BEGIN Block ausgeführt wird, warum erzeugt es dann nicht, wie my $stuff = 0 das offenbar tut, eine neue lexikalische Variable, die die alte globale verdeckt?

Bei meinem Perl gibt das Beispiel mit "my $stuff = undef;" übrigens keine Warnung!

Code: (dl )
1
2
3
4
$ perl --version

This is perl, v5.8.6 built for darwin-thread-multi-2level
[...]
\n\n

<!--EDIT|murphy|1126781614-->
When C++ is your hammer, every problem looks like your thumb.
format_c
 2005-09-15 15:15
#58030 #58030
User since
2003-08-04
1706 Artikel
HausmeisterIn
[Homepage] [default_avatar]
MMh was es mit dem BEGIN Block und der lexokalisierug auf sich hat werd ich heute abend nochmal nachlesen. Aber, dass dein Perl trotz warnings nicht meckert wenn du einge undefinierte Variable ausgibst wundert mich. Zeig mal bitte deinen Code der bei dir ohne warnung funktioniert.

Gruß Alex
renee
 2005-09-15 15:19
#58031 #58031
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
Ihr solltet euch das hier durchlesen: http://www.oreilly.de/catalog/pperl3ger/chapter/ch18.html Dort ist im Lebenszyklus erklärt, was gemacht wird!
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
murphy
 2005-09-15 15:30
#58032 #58032
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
[quote=format_c,15.09.2005, 13:15][...] Zeig  mal bitte deinen Code der bei dir ohne warnung funktioniert.

Gruß Alex[/quote]
Den Code habe ich schon gepostet!

Noch einmal für alle, die es nicht glauben wollen:
Code: (dl )
1
2
3
4
5
6
7
8
$ cat >test.pl
use strict;
use warnings;
my $stuff = undef;
BEGIN { $stuff = 1; }
print "$stuff\n";
$ perl test.pl
1


Keine Fehler, keine Warnungen! Und meine Perlversion steht in meinem letzten Posting.
When C++ is your hammer, every problem looks like your thumb.
murphy
 2005-09-15 15:36
#58033 #58033
User since
2004-07-19
1776 Artikel
HausmeisterIn
[Homepage]
user image
[quote=renee,15.09.2005, 13:19]Ihr solltet euch das hier durchlesen: http://www.oreilly.de/catalog/pperl3ger/chapter/ch18.html Dort ist im Lebenszyklus erklärt, was gemacht wird![/quote]
Danke für den Link. Das erklärt zumindest, warum meine ersten beiden Beispiele sich genau so verhalten wie sie es tun.

Dass aber mein Perl mein letztes Beispiel, bzw. das Beispiel meines letzten Postings, ohne zu murren ausführt und eine 1 ausgibt, halte ich dann für einen handfesten Bug.
When C++ is your hammer, every problem looks like your thumb.
renee
 2005-09-15 15:58
#58034 #58034
User since
2003-08-04
14371 Artikel
ModeratorIn
[Homepage] [default_avatar]
@format_c: welche Perl-Version hast Du??
OTRS-Erweiterungen (http://feature-addons.de/)
Frankfurt Perlmongers (http://frankfurt.pm/)
--

Unterlagen OTRS-Workshop 2012: http://otrs.perl-services.de/workshop.html
Perl-Entwicklung: http://perl-services.de/
<< |< 1 2 3 >| >> 26 Einträge, 3 Seiten



View all threads created 2005-09-15 04:25.