guckst Du hier ...

[quote=docsnyder,14.09.2005, 14:16]guckst Du hier ...[/quote]
schon witzig...
hätt ich nicht gedacht...
ich hätt' mich auch auf mein C verlassen;
damit es auch für die besserwisser verständlicher wird

naja esskar mit deiner methode ist klar, dass $i=0 ist.

dass aber $n = $n++ ebenfalls 0 ist, das ist merkwürdig.

[quote=vayu,14.09.2005, 15:04]naja esskar mit deiner methode ist klar, dass $i=0 ist.[/quote]
stimmt wohl! :)

[quote=vayu,14.09.2005, 15:04]dass aber $n = $n++ ebenfalls 0 ist, das ist merkwürdig.[/quote]
das finde ich ein echt schoenes Beispiel, dass perl durch seine abstraktheit sicherer als C ist. Wo C ohne Ruecksicht auf Verluste auf irgendwelchen Speicheradressen rumroedelt und Variablen veraendert, die es gar nicht veraendern darf, bleibt perl sauber... ich tendiere sogar dazu, das fuer einen Bug in C zu halten... was meint ihr?

perldoc perlop sagt ja, dass ++ stärker bindet als =. Da Post-++ den ursprünglichen Wert zurückliefert, erwartet ich auch logischerweise in Perl, dass sich $n = $n++; wie eine NOP verhält.
Wenn ich die Aussage in perl.de/forum richtig verstehe, verhält sich C also so, als ob ($n=$n)++ ausgeführt wird (übrigens auch unter Perl ein gültiger Ausdruck! ).
Da ich schon ewig nicht mehr mit C gearbeitet habe, ist mir auch die entsprechende Doku schon länger entfleucht.
Offensichtlich kommt mir (schon alleine deshalb) die Perl-Sichtweise natürlicher vor ;)

ok gehen wir eine Stufe weiter ;)



Ausgabe: n: 1, m: 2

achja hab grad mal das C-Snippet übersetzt und bei mir hier in der Firma kommt 0 raus.

Na ja, daß '$n = $n++' Null liefert, kann man so oder so sehen: Da der Inkrement nach der Zuweisung ausgeführt wird, spricht dafür, daß die Null zugewiesen wird. Wenn aber der Inkrement ausgeführt wird, würde man doch erwarten, daß er sich auf die gleiche Speicheradresse bezieht (wie es ja auch in C der Fall ist). Ansonsten hätte man 2 unabhängige Instanzen einer logischen Variablen. Weiter muß man sich dann fragen, was denn bitteschön in aller Welt durch den Inkrement schließlich hochgezählt wird, wenn nicht $n.

Vor vielen vielen Jahren habe ich sogar sowas



durch den C-Compiler gekriegt. Und, wer hätte das gedacht: das Ergebnis war Compiler-abhängig. Eben wohl deshalb, weil eben schwer zu sagen ist, wie solche Konstrukte auszuwerten sind.

Interessant find ich's trotzdem.

Gruß, Doc

[quote=docsnyder,14.09.2005, 15:47]...würde man doch erwarten, daß er sich auf die gleiche Speicheradresse bezieht (wie es ja auch in C der Fall ist). Ansonsten hätte man 2 unabhängige Instanzen einer logischen Variablen. Weiter muß man sich dann fragen, was denn bitteschön in aller Welt durch den Inkrement schließlich hochgezählt wird, wenn nicht $n.[/quote]
Perl bezieht sich eben nicht auf physikalische Dinge wie etwa Speicheradressen. Zum Perl verstehen ist es besser, sich von der Idee ganz zu lösen.

Hier ist mehr ein ideeller Raum, und in dem wurde ein $n sich selbst zugewiesen, dabei wurde der Wert Null übergeben.
Da das Postinkrement nach der Übergabe erfolgt, darf es das $n, an das soeben ein Wert übergeben wurde nicht mehr betreffen, in einem Sandkasten wird also ein anderes $n um 1 hochgezählt, aber das wird gleich wieder vergessen, weil es doch nicht weiter bedeutsam ist.

Was sollte es auch sonst tun? Würde es nach der Zuweisung nochmals auf das bestehenbleibende $n zugreifen, dann würde die Zuweisung ja nicht korrekt funktionieren. Dies nicht der Postinkrementanweisung zu opfern war wohl eine Designentscheidung. Da ich Perl gewöhnt bin, erscheint diese mir nur natürlich... aber das liegt wohl auch stark an der Konditionierung.

dagegen ergibt einen syntax error.