and, or, not vs. &&, ||, !
Manuel Reimer
das es verschiedene M�glichkeiten gibt, leuchtet ja noch ein. So kann
man sich aussuchen, welche Syntax einem besser gef�llt und Perl ist ja
daf�r bekannt, dass es immer mehr als eine M�glichkeit gibt, um etwas zu
machen.
Komisch finde ich aber, dass die "Dinger" sich unterschiedlich
verhalten.
Beispiel:
if (!-d $path && !mkdir($path)) {
die("mkdir failed for $path");
}
verh�lt sich so, wie ich es erwarten w�rde. Perl pr�ft erst nach, ob das
Verzeichnis existiert und wenn nicht, dann wird versucht es zu
erstellen. Beides fehlgeschlagen? Dann Fehler und Ende.
Schreibe ich das gleiche so:
if (not -d $path && not mkdir($path)) {
die("mkdir failed for $path");
}
dann bekomme ich nur noch den Fehler und es wird garkein Verzeichnis
mehr erstellt.
Frage also: Warum so eine Verwirrung? Wo ist der Unterschied zwischen
der "englischen Syntax" und der Syntax mit den Sonderzeichen?
Gleiche Kritik k�nnte man anbringen bei "==, !=, <, >, ..." vs. "eq, ne,
lt, gt, ...". Hier habe ich zwar verstanden, dass erstere f�r Zahlen und
letztere f�r Strings verwendet werden, aber der Sinn der Unterscheidung
erschlie�t sich mir auch hier nicht, zumal ich von diesen
"String-Funktionen" bisher nur "eq" und "ne" verwendet habe. Wirklich
einen Sinn im Vergleich der "gr��e" eines Strings habe ich noch nie
gesehen. Wann nutzt man sowas? Beim Basteln von Sortieralgorithmen?
CU
Manuel
--
Alle wollen zur�ck zur Natur - aber keiner zu Fu�
Der Mensch erfand Maschinen, um sich damit die Arbeit zu erleichtern.
Nur leider hat er vergessen, rechtzeitig damit aufzuh�ren...
Beitr�ge mit *X-No-Html Header* kann ich weder lesen, noch beantworten!
Michael van Elst
>Frage also: Warum so eine Verwirrung? Wo ist der Unterschied zwischen
>der "englischen Syntax" und der Syntax mit den Sonderzeichen?
In der Priorit�t der Operatoren. In der Regel sollte man &&,||,! innerhalb
eines Ausdrucks verwenden und and,or,not f�r Statements, das spart Klammern
und sieht auch schicker aus. Machen aber die wenigsten und fallen dann
immer �ber die dann doch seltsamen Priori�ten.
>Gleiche Kritik k�nnte man anbringen bei "==, !=, <, >, ..." vs. "eq, ne,
>lt, gt, ...". Hier habe ich zwar verstanden, dass erstere f�r Zahlen und
>letztere f�r Strings verwendet werden, aber der Sinn der Unterscheidung
>erschlie�t sich mir auch hier nicht, zumal ich von diesen
>"String-Funktionen" bisher nur "eq" und "ne" verwendet habe.
Zahlen kann man auch als Strings vergleichen und Strings als Zahlen.
Das Ergebnis ist durchaus unterschiedlich und du musst halt irgendwie
vorgeben, wie es gemeint ist. Das ist die Folge davon, dass Variablen
in perl nicht wirklich einen Typ haben.
>Wirklich
>einen Sinn im Vergleich der "gr��e" eines Strings habe ich noch nie
>gesehen. Wann nutzt man sowas? Beim Basteln von Sortieralgorithmen?
Es wird auch nicht die "gr��e" verglichen, weder L�nge noch Breite
noch Tiefe noch literarischer Gehalt sondern, tada, die Sortierreihenfolge
gem�� ihrer Kodierung. Und basteln muss man da nichts, ist alles
schon eingebaut.
--
--
Michael van Elst
Internet: mle...@serpens.de
"A potential Snark may lurk in every tree."
Frank Seitz
>
> Frage also: Warum so eine Verwirrung? Wo ist der Unterschied zwischen
> der "englischen Syntax" und der Syntax mit den Sonderzeichen?
Die Operatoren 'and', 'or', 'not' haben eine niedrigere Pr�zedenz als &&, ||, !.
not $p && not $q
ist
not($p && not($q))
nicht
not($p) && not($q)
> Gleiche Kritik k�nnte man anbringen bei "==, !=, <, >, ..." vs. "eq, ne,
> lt, gt, ...". Hier habe ich zwar verstanden, dass erstere f�r Zahlen und
> letztere f�r Strings verwendet werden, aber der Sinn der Unterscheidung
> erschlie�t sich mir auch hier nicht
Numerische Vergleiche und Stringvergleiche sind verschieden definiert.
Nimm 1.5 und 1.50. Numerisch sind die Werte gleich, als Strings sind sie verschieden.
Nimm 10 und 2. Numerisch ist 10 gr��er als 2, f�r Strings ist es umgekehrt.
> Wirklich
> einen Sinn im Vergleich der "gr��e" eines Strings habe ich noch nie
> gesehen. Wann nutzt man sowas? Beim Basteln von Sortieralgorithmen?
Ja. Stichwort: lexikalische Ordnung.
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/ (Spielwiese)
XING-Profil: http://www.xing.com/profile/Frank_Seitz2
Manuel Reimer
> Die Operatoren 'and', 'or', 'not' haben eine niedrigere Pr�zedenz als
> &&, ||, !.
Wer kommt denn auf solche Ideen...
Eine Suche nach "Pr�zedenz" hat mich �ber ein paar Ecken zu dieser Seite
gebracht:
http://perldoc.perl.org/perlop.html
Soll also hei�en, dass die "englischen Ausdr�cke" immer *zuletzt*
ausgef�hrt werden, egal wo sie stehen?
Manuel Reimer
> In der Priorit�t der Operatoren. In der Regel sollte man &&,||,!
> innerhalb eines Ausdrucks verwenden und and,or,not f�r Statements, das
> spart Klammern und sieht auch schicker aus.
Also
if ($var1 eq ... || $var2 == ...) {...
und
my_function(...) or die();
Aber was ist denn in meinem urspr�nglichem Fall die bessere/sauberere
L�sung:
if (!-d $path && !mkdir($path)) {
die("mkdir failed for $path");
}
oder
if (not -d $path and not mkdir($path)) {
die("mkdir failed for $path");
}
CU
Frank Seitz
>
> Soll also hei�en, dass die "englischen Ausdr�cke" immer *zuletzt*
> ausgef�hrt werden, egal wo sie stehen?
Ich wei� zwar nicht, was du mit "egal wo sie stehen" meinst.
Aber sie haben die allerniedrigste Pr�zedenz, ja. Und untereinander die
Rangfolge, wie man sie bei logischen Operatoren erwartet.
Moritz Lenz
> Frank Seitz wrote:
>> Die Operatoren 'and', 'or', 'not' haben eine niedrigere Pr�zedenz als
>> &&, ||, !.
>
> Wer kommt denn auf solche Ideen...
Vermutlich ein Linguist (Larry).
Die Idee dahinter ist, dass man auch in nat�rlicher Sprache gruppieren
kann. Z.B. ist "und" und "ausserdem" semantisch quasi das gleiche,
allerdings bezieht sich "ausserdem" fast immer auf den vorherigen
Teilsatz, w�hrend sich "und" auch auf Elemente einer Aufz�hlung beziehen
kann, also in Analogie zu Perl einen h�heren Operatorvorrang hat.
Die �bersetzung von
open $handle, '-|' $program, $arg1 || $arg2
or die "Can't open pipe: $!";
ist also ungef�hr
Starte $programm mit $arg1 oder $arg2; Ansonsten stirb.
Durch "Ansonsten" anstatt von "oder" ist klar, dass sich das nicht mehr
auf "$arg1 oder $arg2" beziehen kann.
> Eine Suche nach "Pr�zedenz" hat mich �ber ein paar Ecken zu dieser Seite
> gebracht:
> http://perldoc.perl.org/perlop.html
>
> Soll also hei�en, dass die "englischen Ausdr�cke" immer *zuletzt*
> ausgef�hrt werden, egal wo sie stehen?
Sie werden zumindest ausgef�hrt, nachdem ihre linke Seite ausgef�hrt wurde.
Gr��e,
Moritz
--
Moritz Lenz
http://perl-6.de/ http://moritz.faui2k3.org/
Michael van Elst
>Aber was ist denn in meinem urspr�nglichem Fall die bessere/sauberere
>L�sung:
reine Geschmackssache.
>if (!-d $path && !mkdir($path)) {
> die("mkdir failed for $path");
>}
Ich schreibe das meistens so:
unless (-d $path) {
mkdir $path or die "mkdir failed for $path ($!)\n";
Frank Seitz
>
> Die �bersetzung von
>
> open $handle, '-|' $program, $arg1 || $arg2
> or die "Can't open pipe: $!";
>
> ist also ungef�hr
>
> Starte $programm mit $arg1 oder $arg2; Ansonsten stirb.
>
> Durch "Ansonsten" anstatt von "oder" ist klar, dass sich das nicht mehr
> auf "$arg1 oder $arg2" beziehen kann.
Ich finde das sprachlich recht weit hergeholt. Der Operator
hei�t schlie�lich "or" und nicht "otherwise". Die niedrig pr�zedenten
Operatoren bieten einfach den Vorteil, dass man Klammern
weglassen kann.
>> Soll also hei�en, dass die "englischen Ausdr�cke" immer *zuletzt*
>> ausgef�hrt werden, egal wo sie stehen?
>
> Sie werden zumindest ausgef�hrt, nachdem ihre linke Seite ausgef�hrt wurde.
not hat keine linke Seite.
Peter J. Holzer
> Manuel Reimer <mre...@expires-30-11-2009.news-group.org> writes:
>>Frage also: Warum so eine Verwirrung? Wo ist der Unterschied zwischen
>>der "englischen Syntax" und der Syntax mit den Sonderzeichen?
>
> In der Priorit�t der Operatoren. In der Regel sollte man &&,||,!
> innerhalb eines Ausdrucks verwenden und and,or,not f�r Statements, das
> spart Klammern und sieht auch schicker aus. Machen aber die wenigsten
> und fallen dann immer �ber die dann doch seltsamen Priori�ten.
Sehr hilfreich bei sowas ist die Option -p von B::Deparse:
% perl -MO=Deparse,-p -e '
if (not -d $path && not mkdir($path)) {
die("mkdir failed for $path");
}
'
if ((not (-d($path) && (!mkdir($path))))) {
die("mkdir failed for $path");
}
-e syntax OK
% perl -MO=Deparse,-p -e ' if (not -d $path && not mkdir($path)) { die("mkdir failed for $path"); } '
if ((not (-d($path) && (!mkdir($path))))) {
die("mkdir failed for $path");
}
-e syntax OK
% perl -MO=Deparse,-p -e ' if (! -d $path && ! mkdir($path)) { die("mkdir failed for $path"); } '
if (((not -d($path)) and (not mkdir($path)))) {
die("mkdir failed for $path");
}
-e syntax OK
>>Wirklich einen Sinn im Vergleich der "gr��e" eines Strings habe ich
>>noch nie gesehen. Wann nutzt man sowas? Beim Basteln von
>>Sortieralgorithmen?
>
> Es wird auch nicht die "gr��e" verglichen, weder L�nge noch Breite
> noch Tiefe noch literarischer Gehalt sondern, tada, die Sortierreihenfolge
> gem�� ihrer Kodierung. Und basteln muss man da nichts, ist alles
> schon eingebaut.
Der Algorithmus ist eingebaut (was nicht hei�t, dass der immer optimal
w�re), aber die eigentliche Vergleichsfunktion musst Du trotzdem noch
schreiben.
hp