Undefinierte Hash-Referenz
K. Wittrock
ich habe mal gedacht, ich hï¿œtte die Basisfeatures von Perl kapiert. Mein
Problem:
use strict;
use warnings;
my $opts; # ref. to options hash
{
$opts = get_opts(); # get command line options
}
sub get_opts {
use Getopt::Long;
my %opts = ();
my $opts_ok = GetOptions(
\%opts,
'outformat=s', # desired output format
);
$opts_ok or [...........];
print "exists +", exists $opts{outformat}, "+\n";
return \%opts;
}
Funktioniert prima. Allerdings hatte ich bei drag&drop nicht aufgepasst,
wodurch das print ursprï¿œnglich so aussah:
print "exists +", exists $opts->{outformat}, "+\n";
Ich weiￜ, den Fehler hￜtte ich schnell bemerkt, wenn ich nicht denselben
Namen fï¿œr 2 Dinge verwendet hï¿œtte. Davon mal abgesehen: Nach meinem
Verstï¿œndnis ist wï¿œhrend der Ausfï¿œhrung des falschen print dem (de facto
globalen) Skalar $opts noch kein Wert zugewiesen. Wieso kommt dann kein
Laufzeitfehler?
Gruￜ
Klaus
--
Persï¿œnliche Antwort bitte nur an
K<ohne_Punkt_und_Komma>Wittrock<Klammeraffe>web.de
Frank Seitz
Stichwort: Autovivification. Ein undefinierter Skalar wird zu einer
Referenz, wenn du ihn als Referenz benutzt.
Grￜￜe
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen fï¿œr Ihr Internet und Intranet
Tel: 04103/180301; Fax: -02; Industriestr. 31, 22880 Wedel
Homepage: http://www.frank-seitz.de/
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
K. Wittrock
"Frank Seitz" <devnu...@web.de> schrieb im Newsbeitrag
news:7of70cF...@mid.individual.net...
Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
er eine Null, aber er bleibt undefiniert. Und immerhin bekommt man dabei
die Warnung "Use of uninitialized value in addition (+) at ...". Ich
meine mich zu erinnern, dass man Warnungen zu fatalen Fehlern hochstufen
kann. Kann man irgendwie erreichen, dass Autovivification zu einer
Warnung oder einem fatalen Fehler fï¿œhrt?
Ich hoffe sehr, dass bei der Autovivification auch das Referenzziel
vernï¿œnftig angelegt wird, in meinem Fall also als anonymer Hash. Denn
ich kann da auch Hashwerte abspeichern, und die sollten nicht irgendwo
landen.
Frank Seitz
> "Frank Seitz" <devnu...@web.de> schrieb im Newsbeitrag
> news:7of70cF...@mid.individual.net...
>>
>> Referenz, wenn du ihn als Referenz benutzt.
>
> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
> er eine Null, aber er bleibt undefiniert. Und immerhin bekommt man dabei
> die Warnung "Use of uninitialized value in addition (+) at ...".
Das ist auch etwas anderes.
> Ich meine mich zu erinnern, dass man Warnungen zu fatalen Fehlern hochstufen
> kann. Kann man irgendwie erreichen, dass Autovivification zu einer
> Warnung oder einem fatalen Fehler fï¿œhrt?
Wozu sollte das gut sein?
> Ich hoffe sehr, dass bei der Autovivification auch das Referenzziel
> vernï¿œnftig angelegt wird, in meinem Fall also als anonymer Hash. Denn
> ich kann da auch Hashwerte abspeichern, und die sollten nicht irgendwo
> landen.
Fï¿œr den Hash wird keine zusï¿œtzliche Variable erzeugt, falls du
das befï¿œrchtest, er ist allein ï¿œber die Referenz erreichbar.
Grￜￜe
Frank Seitz
K. Wittrock
> K. Wittrock wrote:
>> "Frank Seitz" <devnu...@web.de> schrieb im Newsbeitrag
>> news:7of70cF...@mid.individual.net...
>>>
>>> Stichwort: Autovivification. Ein undefinierter Skalar wird zu einer
>>> Referenz, wenn du ihn als Referenz benutzt.
>>
>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als
>> sei
>> er eine Null, aber er bleibt undefiniert. Und immerhin bekommt man
>> dabei
>> die Warnung "Use of uninitialized value in addition (+) at ...".
>
> Das ist auch etwas anderes.
Das sehe ich nicht so. In beiden Fï¿œllen verwende ich einen undefinierten
Skalar. Das kann gewollt sein, oder schlampige Programmierung, oder ein
Versehen/Fehler.
>
>> Ich meine mich zu erinnern, dass man Warnungen zu fatalen Fehlern
>> hochstufen
>> kann. Kann man irgendwie erreichen, dass Autovivification zu einer
>> Warnung oder einem fatalen Fehler fï¿œhrt?
>
> Wozu sollte das gut sein?
Ich pflege die Dinge, die ich verwende, vorher zu definieren. Ein
undefinierter Wert beruht bei mir daher meist auf einem Fehler. Wenn
Perl so etwas findet, hï¿œtte ich gerne die Mï¿œglichkeit, gewarnt zu
werden.
Frank Seitz
>
> Ich pflege die Dinge, die ich verwende, vorher zu definieren. Ein
> undefinierter Wert beruht bei mir daher meist auf einem Fehler. Wenn
> Perl so etwas findet, hï¿œtte ich gerne die Mï¿œglichkeit, gewarnt zu
> werden.
Es gibt ein Pragma "autovivification" auf CPAN. Ich selber kenne
es nicht (und brauche es nicht), aber mit dem kannst du laut Doku
erreichen, was du mï¿œchtest.
Grￜￜe
Frank
K. Wittrock
> K. Wittrock wrote:
>>
>> Ich pflege die Dinge, die ich verwende, vorher zu definieren. Ein
>> undefinierter Wert beruht bei mir daher meist auf einem Fehler. Wenn
>> Perl so etwas findet, hï¿œtte ich gerne die Mï¿œglichkeit, gewarnt zu
>> werden.
>
> Es gibt ein Pragma "autovivification" auf CPAN. Ich selber kenne
> es nicht (und brauche es nicht), aber mit dem kannst du laut Doku
> erreichen, was du mï¿œchtest.
Hallo Frank,
danke fï¿œr den Hinweis. Ich probiere es mal aus. Ein Testbeispiel habe
ich ja :-))
Gruￜ
Klaus
Ferry Bolhar
>>> use strict;
>>> use warnings;
>>> my $opts; # ref. to options hash
>>> {
>>> $opts = get_opts(); # get command line options
>>> }
>>> sub get_opts {
>>> use Getopt::Long;
>>> my %opts = ();
>>> my $opts_ok = GetOptions(
>>> \%opts,
>>> 'outformat=s', # desired output format
>>> );
>>> $opts_ok or [...........];
>>> print "exists +", exists $opts{outformat}, "+\n";
>>> return \%opts;
>>> }
> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
> er eine Null, aber er bleibt undefiniert. Und immerhin bekommt man dabei
> die Warnung "Use of uninitialized value in addition (+) at ...".
Wo in obigem Code wird eine Addition durchgef�hrt?
PS: Dass f�r einen undefinierten Skalar der numerische Wert 0 eingesetzt
wird, ist normales Perl-Verhalten. Und man wird ja auch dar�ber informiert,
dass der Skalar undefiniert ist. Wo also ist das Problem?
LG, Ferry
--
Ing. Ferry Bolhar
Magistrat der Stadt Wien - MA 14
A-1010 Wien
E-Mail: ferdinand.bolh...@wien.gv.at
Peter J. Holzer
> "K. Wittrock":
>>>> use strict;
>>>> use warnings;
>>>> my $opts; # ref. to options hash
>>>> {
>>>> $opts = get_opts(); # get command line options
>>>> }
>>>> sub get_opts {
>>>> use Getopt::Long;
>>>> my %opts = ();
>>>> my $opts_ok = GetOptions(
>>>> \%opts,
>>>> 'outformat=s', # desired output format
>>>> );
>>>> $opts_ok or [...........];
>>>> print "exists +", exists $opts{outformat}, "+\n";
>>>> return \%opts;
>>>> }
>
>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
>> er eine Null, aber er bleibt undefiniert. Und immerhin bekommt man dabei
>> die Warnung "Use of uninitialized value in addition (+) at ...".
>
> Wo in obigem Code wird eine Addition durchgef�hrt?
Gar nirgends. Hier wird ein undefinierter Skalar dereferenziert und man
bekommt keine Warnung.
> PS: Dass f�r einen undefinierten Skalar der numerische Wert 0 eingesetzt
> wird, ist normales Perl-Verhalten. Und man wird ja auch dar�ber informiert,
> dass der Skalar undefiniert ist. Wo also ist das Problem?
Das ist nicht das Problem sondern das von Wittrock gew�nschte Verhalten.
Er h�tte aber gerne dieses Verhalten (eine Warnung) nicht nur bei der
Addition sondern auch bei einer Dereferenzierung.
hp
Ferry Bolhar
>> Wo in obigem Code wird eine Addition durchgef�hrt?
>
> Gar nirgends.
Der OP hat aber davon geschrieben:
>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
>> er eine Null, aber er bleibt undefiniert.
Was hat er also gemeint?
> Hier wird ein undefinierter Skalar dereferenziert und man
> bekommt keine Warnung.
Das ist aber kein Fehler, sondern liegt am Verhalten von "exists"
und ist in dessen Beschreibung sogar ausdr�cklich erw�hnt:
-----
Although the deepest nested array or hash will not spring into
existence just because its existence was tested, any
intervening ones will. Thus "$ref->{"A"}" and
"$ref->{"A"}->{"B"}" will spring into existence due to the
existence test for the $key element above. This happens
anywhere the arrow operator is used, including even:
undef $ref;
if (exists $ref->{"Some key"}) { }
print $ref; # prints HASH(0x80d3d5c)
This surprising autovivification in what does not at first--or
even second--glance appear to be an lvalue context may be fixed
in a future release.
-----
> Er h�tte aber gerne dieses Verhalten (eine Warnung) nicht nur bei der
> Addition sondern auch bei einer Dereferenzierung.
Tja, it's not a bug, it's a feature, wie oben beschrieben.
BTW: Und nat�rlich bekommt man eine Warnung, sobald man auf
einen Skalar mit dem Wert "undef" lesend zugreift, was bei einem
Element eines anonymen Arrays/Hashes, das gerade frisch
angelegt wurde, naturgem�� immer der Fall ist. Das Problem
ist hier m.M.n die etwas ungew�hnliche Verwendung von "exists"
in einer Ausgabeliste von "print".
K. Wittrock
"Ferry Bolhar" <b...@adv.magwien.gv.at> schrieb im Newsbeitrag
news:12608675...@proxy.dienste.wien.at...
> "Peter J. Holzer":
>
>>> Wo in obigem Code wird eine Addition durchgef�hrt?
>>
>> Gar nirgends.
>
> Der OP hat aber davon geschrieben:
>
>>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als
>>> sei
>>> er eine Null, aber er bleibt undefiniert.
>
> Was hat er also gemeint?
Das mit der Addition war als Analogie gemeint. Tut mir leid, dass das
nicht klar r�ber kam In einem sp�teren Posting habe ich das noch etwas
erl�utert:
| In beiden F�llen verwende ich einen undefinierten
| Skalar. Das kann gewollt sein, oder schlampige Programmierung, oder
ein
| Versehen/Fehler.
| [......]
| Ich pflege die Dinge, die ich verwende, vorher zu definieren. Ein
| undefinierter Wert beruht bei mir daher meist auf einem Fehler. Wenn
| Perl so etwas findet, h�tte ich gerne die M�glichkeit, gewarnt zu
| werden.
Das Thema Warnung ist durch den Hinweis von Frank auf das Pragma
"autovivification" inzwischen erledigt.
>
>> Hier wird ein undefinierter Skalar dereferenziert und man
>> bekommt keine Warnung.
>
> Das ist aber kein Fehler, sondern liegt am Verhalten von "exists"
> und ist in dessen Beschreibung sogar ausdr�cklich erw�hnt:
>
> -----
> Although the deepest nested array or hash will not spring into
> existence just because its existence was tested, any
> intervening ones will. Thus "$ref->{"A"}" and
> "$ref->{"A"}->{"B"}" will spring into existence due to the
> existence test for the $key element above. This happens
> anywhere the arrow operator is used, including even:
>
> undef $ref;
> if (exists $ref->{"Some key"}) { }
> print $ref; # prints HASH(0x80d3d5c)
>
> This surprising autovivification in what does not at first--or
> even second--glance appear to be an lvalue context may be fixed
> in a future release.
> -----
Wenn ich dein Zitat richtig verstehe, liegt es nicht am exists, sondern
am -> ;-) Was auch nicht exakt stimmt, denn die �quivalente
Formulierung
print "exists +", exists $$opts{outformat}, "+\n";
verh�lt sich genauso. Der Schlusssatz des Zitats scheint mir darauf
hinzuweisen, dass sich die Entwickler auch nicht so ganz wohl bei diesem
Aspekt sind.
>
> [.........] Das Problem
> ist hier m.M.n die etwas ungew�hnliche Verwendung von "exists"
> in einer Ausgabeliste von "print".
Im Beispielkode meines OP lasse ich mir das Resultat von Getopt::Long
als Hash liefern. Da muss ich sp�ter jeden Key vor der Verwendung auf
Existenz pr�fen, um Warnungen zu vermeiden. Das print habe ich zu
Testzwecken eingef�gt (deshalb ist es nicht einger�ckt).
Gru�
Klaus
Frank Seitz
>
> Wo also ist das Problem?
Das geht doch aus den ersten Postings hervor.
Kann es sein, Ferry, dass du gelegentlich nur einen Teil
der Artikel liest?
Gr��e
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen f�r Ihr Internet und Intranet
Ferry Bolhar
> Wenn ich dein Zitat richtig verstehe, liegt es nicht am exists, sondern
> am -> ;-) Was auch nicht exakt stimmt, denn die �quivalente
> Formulierung
>
> print "exists +", exists $$opts{outformat}, "+\n";
>
> verh�lt sich genauso. Der Schlusssatz des Zitats scheint mir darauf
> hinzuweisen, dass sich die Entwickler auch nicht so ganz wohl bei diesem
> Aspekt sind.
Ich habe mich wohl unklar ausgedr�ckt - es liegt sicher nicht am ->,
denn die Schreibweisen $opts->{x} und $$opts{x} sind equivalent
(wie man mit B::Deparse schnell erkennt).
Was ich meinte, ist die Autovivification, die "exists" durchf�hrt, wenn
es die Existenz eines Elements pr�ft und dieses �ber eine noch nicht
vorhandene anonyme Hash- oder Arrayreferenz angesprochen wird.
Ich verstehe dein Problem durchaus, wollte nur darauf hinweisen,
dass dieses Verhalten von "exists" beschrieben und bekannt ist. Ob
es immer sinnvoll und w�nschenswert ist, ist eine andere Frage.
Aber mit "autovivification"
Ich vermeide daher - auch wenn es nicht immer ganz sauber ist -
die Verwendung von "exists", da ich in der Regel mehr am Inhalt
eines Array- oder Hashelements interessiert bin, als an seiner
Existenz ansich, d.h., der Unterschied, ob es jetzt existiert und
"undef" enth�lt, oder ob es gar nicht existiert, ist letztlich in den
meisten F�llen gleichg�ltig. Nat�rlich kann es davon Ausnahmen
geben.
Frank Seitz
>
> Ich habe mich wohl unklar ausgedr�ckt - es liegt sicher nicht am ->,
> denn die Schreibweisen $opts->{x} und $$opts{x} sind equivalent
> (wie man mit B::Deparse schnell erkennt).
>
> Was ich meinte, ist die Autovivification, die "exists" durchf�hrt, wenn
> es die Existenz eines Elements pr�ft und dieses �ber eine noch nicht
> vorhandene anonyme Hash- oder Arrayreferenz angesprochen wird.
>
> Ich verstehe dein Problem durchaus, wollte nur darauf hinweisen,
> dass dieses Verhalten von "exists" beschrieben und bekannt ist. Ob
> es immer sinnvoll und w�nschenswert ist, ist eine andere Frage.
> Aber mit "autovivification"
>
> Ich vermeide daher - auch wenn es nicht immer ganz sauber ist -
> die Verwendung von "exists", da ich in der Regel mehr am Inhalt
> eines Array- oder Hashelements interessiert bin, als an seiner
> Existenz ansich, d.h., der Unterschied, ob es jetzt existiert und
> "undef" enth�lt, oder ob es gar nicht existiert, ist letztlich in den
> meisten F�llen gleichg�ltig. Nat�rlich kann es davon Ausnahmen
> geben.
Ich glaube, du beschreibst es nicht richtig, denn exists() f�hrt
keine Autovivification durch. Autovivification ist ein
grundlegender Mechanismus von Perl, der mit dem Aufruf
von exists() nichts zu tun hat. Perl hat bereits
autovivifiziert, *bevor* es exists() aufruft und genau das
ist in dem speziellen Fall nicht unbedingt erw�nscht
und auch nicht das, was man intuitiv erwartet. Deswegen
der Kommentar in der Doku. Um das anders zu machen, m�sste man
tief in die Trickkiste greifen.
Das Problem von Klaus wiederum hatte mit exists()
nichts zu tun, er wollte Autovivification generell nicht haben.
Gr��e
Frank
--
Dipl.-Inform. Frank Seitz
Anwendungen f�r Ihr Internet und Intranet
Ferry Bolhar
>> Wo also ist das Problem?
>
> Das geht doch aus den ersten Postings hervor.
> Kann es sein, Ferry, dass du gelegentlich nur einen Teil
> der Artikel liest?
Nein, ich war nur durch die beschriebene, aber im Code
nicht vorhandene Addition etwas irritiert.
Peter J. Holzer
> "Peter J. Holzer":
>>> Wo in obigem Code wird eine Addition durchgef�hrt?
>>
>> Gar nirgends.
>
> Der OP hat aber davon geschrieben:
>
>>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet, als sei
>>> er eine Null, aber er bleibt undefiniert.
>
> Was hat er also gemeint?
Wie er es gemeint hat, wei� ich nat�rlich auch nicht, ich kann
schlie�lich nicht Gedanken lesen. Aber ich habe es so interpretiert:
Toll (ironisch gemeint, also eigentlich: Gr�sslich). Bei einer Addition
wird zwar auch ein anderer Wert verwendet (0 statt undef), aber immerhin
bleibt die Variable unver�ndert. Das ist also vergleichsweise harmlos,
und man bekommt eine Warnung (das stand dann im n�chsten Satz). Aber
bei so einer hinterh�ltigen Nebenwirkung wie der Autovivification (die
eine Variable hinterr�cks �ndert) bekommt man keine Warnung. Was soll
das !!!1elf!
>> Hier wird ein undefinierter Skalar dereferenziert und man
>> bekommt keine Warnung.
>
> Das ist aber kein Fehler, sondern liegt am Verhalten von "exists"
Wie Frank schon festgestellt hat, liegt das nicht an exists, sondern ist
eine allgemeine Eigenschaft des Dereferenzierungsoperators.
Es w�re aber eventuell w�nschenswert, wenn Autovivification f�r das
Argument von exists unterdr�ckt werden k�nnte.
[...]
>> Er h�tte aber gerne dieses Verhalten (eine Warnung) nicht nur bei der
>> Addition sondern auch bei einer Dereferenzierung.
>
> Tja, it's not a bug, it's a feature, wie oben beschrieben.
>
> BTW: Und nat�rlich bekommt man eine Warnung, sobald man auf
> einen Skalar mit dem Wert "undef" lesend zugreift,
Nein:
my $x = undef;
my $y = $x; # lesender Zugriff
ergibt keine Warnung. Und das ist auch gut so.
Erst wenn Du diesen Wert in einer Addition (um bei Wittroks Beispiel zu
bleiben) verwendest, bekommst Du eine Warnung:
$y = $x + 2;
Use of uninitialized value $x in addition (+) at ./ferry line 8.
Es ist hier also der Operator "+", der eine Warnung ausgibt, wenn einer
seiner Operatoren nicht definiert ist. Ok.
Wenn Du hingegen einen undefinierten Wert dereferenzierst:
$y = $x->{a};
bekommst Du keine Warnung. Und nicht nur das, es wird still und leise
eine Variable (hier $x) modifiziert, auf die scheinbar nur lesend
zugegriffen wird.
Nat�rlich ist das dokumentiert und "Autovivification" sollte dem
Perl-Programmierer ein Begriff sein (es ist manchmal auch sehr
praktisch). Aber man kann sich doch dar�ber wundern, warum eine
vergleichsweise harmlose Operation wie die Addition eines undefinierten
Werts eine Warnung verursacht, w�hrend eine �nderung des Werts einer
Variable ohne explizite Zuweisung keine Warnung wert ist.
hp
Peter Tuente
ich stimme Dir hp v�llig zu. Ich f�nde es ja noch OK, wenn die
"Autovivification" nur dann stattfinden w�rde wenn der undefinierte
Skalar $x als L-Value verwendet w�rde, dann w�re es ein netter Komfort:
$x->{a} = $z;
Der "scheinbar nur lesende" Zugriff:
>
> $y = $x->{a};
>
sollte aber zumindest eine Warnung werfen.
PiT
K. Wittrock
> Ferry Bolhar wrote:
> [..............]
> Das Problem von Klaus wiederum hatte mit exists()
> nichts zu tun, er wollte Autovivification generell nicht haben.
Da bin ich nicht so sicher. Ich bemerke bestimmt oft nicht, wenn
Autovivification im Hintergrund abl�uft, und k�nnte es vermissen, wenn
es generell abgeschaltet w�re. (Ich habe das Pragma, auf das Frank mich
aufmerksam machte, heruntergeladen, aber noch nicht ausprobiert.) Mich
st�rt aber, dass Perl manchmal nicht meldet, dass ich einen nicht
initialisierten Skalar verwende. In meinem Fall hatte Perl
freundlicherweise die Optionen in einem anonymen Hash geliefert. Ich
habe dann mit meinem benannten Hash weitergearbeitet und mich gewundert,
warum da keine Optionen drin stehen.
Gru�
Klaus
--
Pers�nliche Antwort bitte nur an
K. Wittrock
> "K. Wittrock":
> [........]
> Ich vermeide daher - auch wenn es nicht immer ganz sauber ist -
> die Verwendung von "exists", da ich in der Regel mehr am Inhalt
> eines Array- oder Hashelements interessiert bin, als an seiner
> Existenz ansich, d.h., der Unterschied, ob es jetzt existiert und
> "undef" enth�lt, oder ob es gar nicht existiert, ist letztlich in den
> meisten F�llen gleichg�ltig. Nat�rlich kann es davon Ausnahmen
> geben.
Z. B. wenn man sich die Optionen der Kommandozeile von Getopt::Long als
Hash zur�ckliefern l�sst. Nur so kann man bequem erkennen, ob eine
bestimmte Option dort angegeben war.
Gru�
Klaus
--
Pers�nliche Antwort bitte nur an
K. Wittrock
"Peter J. Holzer" <hjp-u...@hjp.at> schrieb im Newsbeitrag
news:slrnhifsji.c8...@hrunkner.hjp.at...
> On 2009-12-15 08:58, Ferry Bolhar <b...@adv.magwien.gv.at> wrote:
>> "Peter J. Holzer":
>>>> Wo in obigem Code wird eine Addition durchgef�hrt?
>>>
>>> Gar nirgends.
>>
>> Der OP hat aber davon geschrieben:
>>
>>>> Toll. Ein undefinierter Skalar wird in einer Addition verwendet,
>>>> als sei
>>>> er eine Null, aber er bleibt undefiniert.
>>
>> Was hat er also gemeint?
>
> Wie er es gemeint hat, wei� ich nat�rlich auch nicht, ich kann
> schlie�lich nicht Gedanken lesen.
Doch, das hast du sogar gut hingekriegt.
>
> Bei einer Addition
> wird zwar auch ein anderer Wert verwendet (0 statt undef), aber
> immerhin
> bleibt die Variable unver�ndert. Das ist also vergleichsweise harmlos,
Wie man's nimmt. Die Chancen stehen nicht schlecht, dass da eigentlich
ein ganz anderer Wert h�tte drinstehen sollen. Das Programm l�uft sauber
durch, nur sind leider die Ergebnisse falsch. Deshalb bem�he ich mich,
alle Warnungen auszumerzen (viele sind ja wirklich harmlos). Im Falle
der Addition z. B. ist es trotzdem gut, dass nur eine Warnung kommt, das
Programm also weiter l�uft. Dadurch kann man auf weitere Fehler sto�en,
das Debuggen geht also schneller.
> und man bekommt eine Warnung (das stand dann im n�chsten Satz). Aber
> bei so einer hinterh�ltigen Nebenwirkung wie der Autovivification (die
> eine Variable hinterr�cks �ndert) bekommt man keine Warnung. Was soll
> das !!!1elf!
>
>>> Hier wird ein undefinierter Skalar dereferenziert und man
>>> bekommt keine Warnung.
>>
>> Das ist aber kein Fehler, sondern liegt am Verhalten von "exists"
>
> Wie Frank schon festgestellt hat, liegt das nicht an exists, sondern
> ist
> eine allgemeine Eigenschaft des Dereferenzierungsoperators.
>
> Es w�re aber eventuell w�nschenswert, wenn Autovivification f�r das
> Argument von exists unterdr�ckt werden k�nnte.
Das finde ich auch. Beim Hash greift man mit exists formal auf einen
Wert zu, will aber nur auf die Existenz des Keys pr�fen.
... zumal Perl nicht sicher sein kann, ob die Variable wirklich eine
Hash-Referenz (oder �berhaupt eine Referenz) enthalten soll.
Gru�
Klaus
--
Pers�nliche Antwort bitte nur an
Frank Seitz
> "Frank Seitz" <devnu...@web.de> schrieb im Newsbeitrag
> news:7opodgF...@mid.individual.net...
>>
>> nichts zu tun, er wollte Autovivification generell nicht haben.
>
> Da bin ich nicht so sicher. Ich bemerke bestimmt oft nicht, wenn
> Autovivification im Hintergrund abl�uft, und k�nnte es vermissen, wenn
> es generell abgeschaltet w�re.
Dann wei�t du offensichtlich nicht was du willst...
> (Ich habe das Pragma, auf das Frank mich
> aufmerksam machte, heruntergeladen, aber noch nicht ausprobiert.)
...und ich h�tte mir sparen k�nnen, auf CPAN f�r dich nachzusehen.
> Mich st�rt aber, dass Perl manchmal nicht meldet, dass ich einen nicht
> initialisierten Skalar verwende. In meinem Fall hatte Perl
> freundlicherweise die Optionen in einem anonymen Hash geliefert. Ich
> habe dann mit meinem benannten Hash weitergearbeitet und mich gewundert,
> warum da keine Optionen drin stehen.
Tja, so ist das eben. Wir machen in der Programmierung alle
Fehler, davor kann einen nichts und niemand sch�tzen.
Ferry Bolhar
>> BTW: Und nat�rlich bekommt man eine Warnung, sobald man auf
>> einen Skalar mit dem Wert "undef" lesend zugreift,
>
> Nein:
>
> my $x = undef;
> my $y = $x; # lesender Zugriff
>
> ergibt keine Warnung. Und das ist auch gut so.
Da habe ich mich wohl unklar ausgedr�ckt. Ich meinte, sobald ein
solcher Skalar als Teil eines Ausdrucks verwendet wird. Nat�rlich
ist es legitim, den Wert "undef" von einem Skalar in einen anderen
zu kopieren, und daher gibt es hier auch keine Warnung. Schreibt
man hingegen
my $y = $x + 1;
d.h., auf der rechten Seite einen Ausdruck, gibt's sehr wohl eine
Warnung.
K. Wittrock
> K. Wittrock wrote:
>> "Frank Seitz" <devnu...@web.de> schrieb im Newsbeitrag
>> news:7opodgF...@mid.individual.net...
>>>
>>> Das Problem von Klaus wiederum hatte mit exists()
>>> nichts zu tun, er wollte Autovivification generell nicht haben.
>>
>> Da bin ich nicht so sicher. Ich bemerke bestimmt oft nicht, wenn
>> Autovivification im Hintergrund abl�uft, und k�nnte es vermissen,
>> wenn
>> es generell abgeschaltet w�re.
>
> Dann wei�t du offensichtlich nicht was du willst...
Ich wei� das sehr wohl. Schon in meinem OP habe ich mich nicht �ber
Autovivification beklagt, sondern bem�ngelt, dass ich bei Verwendung
eines undefinierten Skalars keine Meldung erhalten habe. Deine oben
zitierte Bemerkung
| Das Problem von Klaus wiederum hatte mit exists()
| nichts zu tun, er wollte Autovivification generell nicht haben.
trifft nicht den Kern meiner Einstellung.
>
>> (Ich habe das Pragma, auf das Frank mich
>> aufmerksam machte, heruntergeladen, aber noch nicht ausprobiert.)
>
> ...und ich h�tte mir sparen k�nnen, auf CPAN f�r dich nachzusehen.
Komm bitte wieder runter auf den Teppich. Ich bin dir f�r deinen Hinweis
wirklich dankbar, wie ich es auch generell zu sch�tzen wei�, dass ich
hier in der NG schon oft schnelle und qualifizierte Unterst�tzung
gefunden habe. Ich w�rde gern meinerseits mein Wissen hier weiter geben,
aber gerade an diesem Wissen hapert es h�ufig.
Was das Installieren und Testen des Pragmas "autovivification" angeht:
manche Aufgaben, die f�r Andere Routine sind, gehen mir nur langsam von
der Hand. Da ich im Moment knapp an Zeit bin (Weihnachten, danach der
Urlaub), habe ich diese Installation erst mal zur�ckgestellt, obwohl mir
das POD gut gef�llt. Das Pragma scheint mir eine gute Erg�nzung zu "use
strict" zu sein. Vergessen werde ich es nicht - versprochen.
>
>> Mich st�rt aber, dass Perl manchmal nicht meldet, dass ich einen
>> nicht
>> initialisierten Skalar verwende. In meinem Fall hatte Perl
>> freundlicherweise die Optionen in einem anonymen Hash geliefert. Ich
>> habe dann mit meinem benannten Hash weitergearbeitet und mich
>> gewundert,
>> warum da keine Optionen drin stehen.
>
> Tja, so ist das eben. Wir machen in der Programmierung alle
> Fehler, davor kann einen nichts und niemand sch�tzen.
Schon richtig. Und wenn mich Perl auf meine (potentiellen) Fehler
hinweist, wenn es welche findet, bin ich zufrieden.
K. Wittrock
"K. Wittrock" <inv...@invalid.invalid> schrieb im Newsbeitrag
news:4b2a6553$0$7620$9b4e...@newsspool1.arcor-online.net...
>
> [..............]
> Da ich im Moment knapp an Zeit bin (Weihnachten, danach der Urlaub),
> habe ich diese Installation erst mal zur�ckgestellt, obwohl mir das
> POD gut gef�llt. Das Pragma scheint mir eine gute Erg�nzung zu "use
> strict" zu sein. Vergessen werde ich es nicht - versprochen.
Hallo Frank,
ich habe das Pragma "autovivification" im PPM-Repos. von ActivePerl
gefunden, so dass die Installation leicht war. Das Pragma funkt. gut,
ich bekomme meine Meldung und bin zufrieden. Nochmals vielen Dank f�r
den Tipp.
Frank Seitz
>
> Hallo Frank,
>
> ich habe das Pragma "autovivification" im PPM-Repos. von ActivePerl
> gefunden, so dass die Installation leicht war. Das Pragma funkt. gut,
> ich bekomme meine Meldung und bin zufrieden. Nochmals vielen Dank f�r
> den Tipp.
Prima, nichts zu Danken.