spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Nun, es gab ja schon die Feststellung, dass eine Operation (durch einen Operator) und eine Funktion äquivalent sind. Beide erfordern die Auswertung der Eingabe-Werte vor der Ausführung der Operation. Das ist beim ternären Operator, welcher 3 Eingabe-Werte besitzt, aber nicht der Fall, denn er wertet nur 2 der 3 aus. Er besitzt daher eine Control-Flow-Eigenschaft, die nicht äquivalent zu einer Operation/Funktion ist.

Dann wäre && wegen seiner short circuit evaluation auch kein operator.

Hmm, interessanter Einwand. Also hat && auch eine Control-Flow-Eigenschaft.
Dennoch bleibt es ein Operator, sowohl semantisch, als auch grammatikalisch, denn im Gegensatz zu ?: kann es nicht ohne explizite (x=a&&b) oder implizite ( if(a&&b) oder call(a&&b) ) Zuweisung verwendet werden und daher nie ein einzeln stehendes Control-Flow-Statement repräsentieren.

Vielleicht macht es nicht viel Sinn, aber koennen tut man es schon. In php gibts da oefter so verrueckte die() Konstrukte.

Zitat von »BlueCobold«

Dennoch bleibt es ein Operator, sowohl semantisch, als auch grammatikalisch, denn im Gegensatz zu ?: kann es nicht ohne explizite (x=a&&b) oder implizite ( if(a&&b) oder call(a&&b) ) Zuweisung verwendet werden und daher nie ein einzeln stehendes Control-Flow-Statement repräsentieren.

Klar kann es ohne explizite Zuweisung verwendet werden, es ist doch ein Operator, genau wie ?:.
Btw: Wenn man && überlädt verliert es seine "Control-Flow-Eigenschaft"

Ohne explizite oder implizite. Zeig mir mal so ein Ding.

Hier bitte:


Btw: ich seh nicht wo in if(a&&b) eine "implizite Zuweisung" passieren soll...

Au, das geht ja wirklich. Spannend. Man, C++ is echt schon wieder so lange her
Wie auch immer.

Zitat von »BlueCobold«

C++ kennt keinen Control Flow? Ähm... Es mag ja gestern spät gewesen sein, aber Du weißt schon, dass z.B. If, For, Do, While, Goto, Break, Return, Continue, Switch in die Klasse der Control Flow Statements gehören?

Natürlich ist mir das bekannt, aber da control flow im Standard nirgends definiert ist kann ich nicht sagen was da jetzt genau dazugehört und was nicht. Wenn es darum geht, dass irgendwo in Assemblerebene ein Jump gemacht wird, dann ist gehört so ziemlich alles zu Control flow.

Zitat

Der ganze Teil bezüglich regulärer Sprachen und Ausdrücke hat damit gar nichts zu tun, wenn man sich auf deren Funktionsweise bezieht, wie ich es eben tue.

Du hast dich hier ganz klar nicht auf ein Verhalten bezogen, sondern irgendeine Behauptung gebracht:

Zitat

Es ist ja auch kein Operator in diesem Sinne, sondern eine bedingte Wertzuweisung.

welche so einfach nicht korrekt ist, darum habe ich es mir erlaubt Namen, wie sie definiert sind zu erklären. Wenn du solches Sachen, wie da behauptest, dann bitte auch mit den dazu gehörenden Definitionen (welche ich verlangt habe), wie du es verstehst, denn der Standard sieht das anders.
Im übrigen habe ich bereits gesagt, dass ich dir Recht gebe, wenn man alleine an der Funktionsweise interessiert ist. Dann kann man das natürlich ansehen, wie man will. Es ging mir von meinem ersten Post an um den korrekten Gebrauch der gegebenen Definitionen um eben solche Missverständnisse zu vermeiden.

Zitat

Ein If berechnet also nichts und wertet wohl auch beide Parameter nicht aus? Das ist ja spannend. Ich dachte immer es wertet einen Boolean zur Bestimmung des Control Flows aus. Und meist ist dieser Boolean berechnet durch einen Compare Operator (spätestens in asm durch einen conditional jump findet somit eine Berechnung statt).

Ich habe nicht gesagt, dass es keine Berechnung durchführt, sondern, dass es keine Berechnung darstellt.

Control-Flow beschreibt lediglich die Beeinflussung von Befehls-Sequenzen. Das ist absolut losgelöst von Assembler und existiert unabhängig davon. Und nein, es ist eben nicht alles Control-Flow. Auch nicht "ziemlich".

Mit dem Rest sind wie ja scheinbar durch und der ist abhängig vom Standpunkt auf den man sich bezieht.